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Abstract 

Object-Oriented  Design  GOD;  has  become  a  popular  approach  to 
‘lopment  with  Ada.  One  of  the  difficulties  in  applying  OOD  is  that  the  in  for¬ 
ma:  ion  available  *o  the  designer  (the  product  of  requirements  analysis!  is  typically 
pr-'sented  in  a  form  inappropriate  to  OOD.  Traditional  requirements  analysis  tools 
<e.g.  data  flow  diagrams)  organize  the  software  requirements  based  upon  the  func¬ 
tions  the  svstem  must  perform.  Recent  research  suggests  that,  an  abject 
approach  to  requirements  analysis  is  a  more  natural  lead-in  to  OOD. 

The  goai  of  this  thesis  was  to  define  the  tools,  steps,  and  heuristics  for  an 
object-oriented  analysis  iOOA:  method  of  modeling  software  requirements.  The 
choice  of  tools  used  to  capture  the  requirements  makes  the  method  particularly 
suitable  for  use  when  developing  embedded  systems.  The  method  emphasizes  com¬ 
munication  with  both  the  domain  expert  and  the  designer. 

The  OOA  method  consists  of  two  phases.  The  objective  of  the  first,  phase  is  to 
capture  the  software  requirements  using  unstructured  tools  such  as  concept  maps, 
storyboards,  and  a  list  of  external  events  to  which  the  system  must  respond.  The 
second  phase  involves  structuring  these  requirements  into  a  model  based  upon  the 

software  objects. 

* 

The  thesis  also  addressed  the  possibility  of  automated  support  for  the  OOA 
method,  and  proposes  an  OOA  tool  to  assist  the  analyst.  The  OOA  method  was 
applied  to  a  sample  requirements  analysis  problem  to  demonstrate  me  method's 
fens;  bill  tv. 
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AN  OBJECT  ORIENTED  ANALYSIS  METHOD 
FOR  Ada  AND  EMBEDDED  SYSTEMS 


I.  Introduction 

The  object-oriented  approach  to  software  development  is  entering  its  adoles¬ 
cence.  Discussions  about  the  object-oriented  paradigm  now  routinely  appear  in  the 
computing  literature,  as  practitioners  recognize  its  potential  benefits  in  develop¬ 
ing  reliable,  maintainable  software.  This  thesis  examines  the  application  of  object- 
oriented  techniques  during  the  requirements  analysis  phase  of  software  development. 

1.1  Background 

In  the  1970s.  the  Department  of  Defense  (DoD)  experienced  first-hand  the 
symptoms  of  the  software  crisis:  unpredictable  development  costs  ami  schedules, 
poor  software  reliability,  costly  maintenance,  and  delivered  software  failing  to  meet 
the  needs  of  the  user  [Booch.  1983:6-7).  As  one  step  toward  resolving  this  predica¬ 
ment.  the  DoD  sponsored  the  design  of  a  new  programming  language.  Ada.  to  be 
used  for  the  development  of  embedded  systems  applications  for  the  military.  The 
Ada  language  includes  features  (e.g.  strong  typing,  packages,  and  tasks)  which  aid 
software  engineers  in  managing  the  complexity  of  large  software  systems. 

I  he  availability  of  these  modern  language  constructs  in  Ada  required  software 
engineers  to  formulate  new  methods  to  utilize  them.  Russell  Abbott  [Abbott.  RKll 
and  Grady  Booch  [Booch,  1983]  introduced  the  use  of  object-oriented  techniques  as 
a  means  of  applying  the  new  features  of  Ada  to  combat  software  complexity.  The 
structure  of  software  developed  with  an  object-oriented  approach  is  patterned  on 
the  objects  evident  in  the  real-world  problem.  A  designer  creates  software  entities  to 
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implement-  these  objects.  The  resulting  similarity  between  the  structure  of  the  prob¬ 
lem  and  that  of  the  solution  tends  to  produce  a  more  natural  design  than  a  design 
mapped  only  into  the  predefined  data  and  control  structures  of  a  typical  program¬ 
ming  language.  The  object-oriented  approach  to  software  development  is  unique  in 
its  ability  to  support  the  principles  of  abstraction,  information  hiding,  and  mod¬ 
ularity  [Pressman,  1987:334]  which  lead  to  more  understandable  and  maintainable 
soft  ware. 

This  original  Object-Oriented  Design  (OOD)  method  called  for  the  develop¬ 
ment  of  a  textual  informal  strategy  of  the  solution  to  be  used  as  the  foundation  for 
the  design  phase.  From  this  informal  strategy,  the  designer  identified  the  relevant 
objects  and  operations  required  for  the  solution  of  the  problem.  Unfortunately,  nei¬ 
ther  Abbott  nor  Booch  gave  much  guidance  for  writing  the  informal  strategy.  In 
practice,  the  typical  result  is  a  vague,  unstructured  paragraph  which  serves  as  a  frail 
basis  for  the  design. 

Recent  research  suggests  the  use  of  object-oriented  techniques  in  the  earlier 
phase  of  requirements  analysis  provides  a  more  coherent  approach  to  object-oriented 
development  [Pressman,  1987,  EVB,  1989,  Ladden,  1989],  A  complete  life  cycle 
object-oriented  methodology  provides  a  stronger  framework  for  the  application  of 
Ada  in  the  management  of  software  complexity. 

A  recent  thesis  by  C’apt  Patrick  Barnes  [Barnes.  1988]  proposed  an  Object 
Oriented  Design  methodology  based  on  the  concepts  of  decision  support  systems. 
Barnes  suggests  that,  a  graphical  concept  map  may  be  a  better  means  of  describ¬ 
ing  the  solution  strategy  than  Booch's  informal  strategy  method  [Barnes.  19.88:3-5]. 
and  recommends  research  into  the  use  of  concept  maps  in  the  requirements  phase. 

I  1 1 is  thesis  further  explores  the  idea  of  using  graphical  object-oriented  tools  in  the 
requirements  analysis  phase  as  a  substitute  for  the  textual  informal  strategy. 


1.3  Problem  Definition 


The  objective  of  this  thesis  is  to  develop  an  Object  Oriented  Analysis  (OOA) 
method  to  model  software  requirements.  This  analysis  method  will  provide  guidelines 
for  identifying  the  objects  in  the  problem  space,  their  attributes,  and  the  relation¬ 
ships  among  the  objects.  The  specific  objectives  of  this  thesis  are  to 


a.  Determine  the  requirements  of  an  OOA  method. 

b.  Define  the  steps  of  an  OOA  method  to  represent  the  problem  space. 

c.  Identify  the  requirements  for  a  software  tool  to  assist  an  analyst  in 
applving  the  OOA  method. 

d.  Validate  the  OOA  method  by  applying  it  to  a  sample  requirements 
analysis  problem. 


1.3  Scope 

The  requirements  analysis  method  developed  in  this  thesis  assumes  that  the 
analyst  has  expended  prior  effort  in  defining  the  overall  system  requirements.  There¬ 
fore,  the  method  considers  only  the  software  component  of  a  larger  system.  The 
method  also  ignores  the  analysis  of  factors  such  as  cost,  effort,  schedule,  or  testing: 
only  the  behavioral  requirements  of  the  software  are  addressed. 

The  method  concentrates  mainly  on  the  analysis,  rather  than  the  determina¬ 
tion.  of  requirements.  In  other  words,  the  method  assumes  that  the  user  has  made 
an  effort  to  identify  the  needs  of  the  system,  and  concentrates  on  rnpturiny  and 
documenting  these  requirements  in  a  model  which  forms  the  basis  for  the  soft  war*' 
design  phase.  In  reality,  it  is  often  difficult  to  separate  requirements  determination 
and  analysis  into  distinct  phases.  Therefore,  the  techniques  of  any  analysis  method 
may  have  to  be  applied  iteratively  until  a  satisfactory  set  of  requirements  can  be  de¬ 
fined.  However,  tools  such  as  rapid  prototyping,  which  are  helpful  for  requirements 
determination,  are  not  specifically  included  in  the  OOA  method.  The  result  ol  the 
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00 A  method  is  a  model  of  the  system  which  can  he  understood  by  both  the  user 
and  the  designer. 

Since  Ada  was  originally  developed  to  program  embedded  systems,  the  00 A 
method  will  concentrate  on  this  arena  as  well.  These  systems  seem  well  suited  to 
object-oriented  design,  with  concrete  physical  objects  that  require  modelling  in  soft¬ 
ware.  Embedded  systems  also  tend  to  have  requirements  that  can  be  identified  early 
in  the  life  cycle,  with  a  fairly  well  defined  hardware/seftware  interface.  Although 
the  00A  method  is  aimed  primarily  towards  embedded  systems,  many  of  the  con¬ 
cepts  presented  here  apply  as  well  to  general  software  development.  However,  the 
method  provides  only  limited  support  for  identifying  reusable  objects  or  potentially 
concurrent  objects  and  operations. 

During  the  development  of  the  OOA  method,  consideration  was  given  to  tin- 
complexities  associated  with  specifying  large  software  systems.  As  the  complexity 
and  size  of  the  software  increases,  it  becomes  important  to  view  the  software  from 
various  levels  of  abstraction.  The  OOA  method  therefore  should  support  the  layering 
of  objects  into  hierarchical  levels  of  abstraction. 

The  method  assumes  that  object-oriented  techniques  will  be  used  in  the  de¬ 
sign  phase,  and  that  Ada  will  be  the  implementation  language.  Ada  is  not  a  “true" 
object-oriented  language  in  that  it  doesn't  fully  support  concepts  such  as  inheritance 
and  dynamic  binding;  however,  Ada  can  still  support  a  form  of  object  oriented  pro¬ 
gramming.  The  OOA  method  addresses  object  oriented  concepts  as  Ada  supports 
them.  Given  these  restrictions,  the  analyst  can  use  the  OOA  method  in  combination 
with  OOD  when  the  implementation  language  is  one  that  supports  data  encapsula¬ 
tion  and  information  hiding,  such  as  Ada  or  Modula-2. 

I..j  Approach  and  Overview 

I  his  research  project  consisted  of  four  phases: 
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1.  Aii  investigation  of  current  analysis  techniques. 

2.  Formation  of  the  tools  and  steps  of  the  OOA  method. 

3.  Description  of  an  OOA  tool  to  assist  the  analyst. 

1.  Validation  of  the  method. 

These  phases  were  somewhat  overlapping.  Examining  current  analysis  tech¬ 
niques  prompted  new  ideas  about  the  requirements  and  design  of  the  OOA  method. 
Also,  the  process  of  developing  the  OOA  method  naturally  identified  many  of  the 
requirements  for  the  corresponding  tool. 

1.4.1  Review  of  Current  Analysis  Techniques.  The  first  step  in  formulating 
the  OOA  method  was  a  review  of  the  literature  to  identify  the  current  state  of 
practice.  Since  at  the  outset  of  this  project  little  research  had  been  accomplished  in 
the  application  of  object-oriented  techniques  to  software  requirements  analysis,  the 
review  covered  a  number  of  topics  surrounding  the  issue.  The  first  subject  was  the 
application  of  object-oriented  techniques  during  the  later  phase  of  software  design. 
The  second  area  addressed  was  the  software  definition  phase.  This  examination 
identified  the  information  captured  during  requirements  analysis,  and  the  major 
tools  and  approaches  used  to  capture  this  information.  Finally,  the  review  considered 
the  attempts  that  have  been  made  in  applying  the  object-oriented  paradigm  to  the 
definition  phase.  Chapter  II  of  this  thesis  discusses  the  results  of  this  literature 
review. 

l..j.2  OOA  Method  Development.  The  requirements  for  the  object-oriented 
analysis  method  were  based  on  the  information  gathered  during  the  literature  review. 
I  he  review  of  the  OOD  process  identified  the  information  needed  in  the  requirements 
model  to  successfully  apply  object-oriented  design.  The  specific  tools  and  steps  of 
the  OOA  method  were  then  developed  from  these  requirements.  The  requirements 
for.  and  stops  of.  the  OOA  method  are  described  in  Chapter  III. 


A  good  deal  of  creativity  was  required  to  conceive  the  steps  of  the  OOA  met  hod. 
A  promising  starting  point  was  to  first  conceive  the  end  components  of  the  object- 
oriented  mode!  of  the  software  requirements.  These  model  components  were  selected 
to  represent  all  of  the  information  required  for  an  object-oriented  design.  Another 
factor  influencing  the  tool  selection  was  the  need  to  define  a  model  which  could  be 
easily  understood  by  both  the  users  and  developers  of  the  software. 

With  this  end  result  defined,  attention  was  then  directed  toward  identifying  the 
steps  and  heuristics  that  go  into  developing  the  mode]  components.  These  guidelines 
were  defined  in  sufficient  detail  to  enable  an  analyst  to  identify  the  objects  and 
operations  of  the  problem  at  various  levels  of  abstraction. 

1.J.3  Requirements  for  an  OOA  Tool.  As  the  steps  and  tools  of  the  OOA 
method  were  defined,  consideration  was  given  to  their  automated  support.  Par¬ 
ticular  attention  was  given  to  die  representations,  operations,  memory  aids,  and 
control  aids  (ROMC-see  [Sprague  and  Carlson.  1.982])  of  a  tool  to  support  the  OOA 
method.  Concept  maps  identified  the  elements  of  the  OOA  method  and  the  relation¬ 
ship  between  the  method  steps.  Once  the  potential  support  areas  were  identified, 
the  proposed  OOA  tool  was  described  through  story  boards.  The  description  of  an 
object-oriented  analysis  tool  is  outlined  in  Chapter  IV. 

I.4.4  Method  Validation.  The  concepts  defined  in  OOA  method  were  vali¬ 
dated  through  application  of  the  method  on  a  sample  problem.  The  problem  se¬ 
lected  to  validate  the  method  needed  to  be  of  sufficient  size  and  complexity  to  give  a 
reasonable  demonstration  of  the  method,  yet  small  enough  to  handle  in  an  academic 
environment..  The  classic  “elevator  problem'1  was  chosen  for  the  task  of  evaluating 
the  method.  This  problem,  originally  used  in  a  workshop  sponsored  by  the  Asso¬ 
ciation  of  Computing  Machinery  (ACM)  [Yourdon,  ]989:fi>.‘{]  ].  calls  for  the  analysis 
of  the  software  requirements  for  an  elevator  control  system  for  a  building  with  lour 
elevators  serving  10  floors. 
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The  tools  and  guidelines  of  the  OOA  method  were  applied  to  analyze  and 
model  the  software  requirements  for  the  elevator  control  system.  The  results  of  this 
exercise  were  compared  against  the  method  goals  identified  in  section  3.1.  Also, 
since  the  elevator  problem  has  been  previously  analyzed  using  different  requirements 
analysis  methodologies,  the  application  of  the  OOA  method  on  this  same  problem 
enabled  a  comparison  to  be  made  between  the  OOA  method  and  previous,  function 
based  analysis  methods.  The  results  of  this  evaluation  are  described  in  Chapter  V. 

1.5  Maximum  Expected  Cain 

The  result  of  this  research  is  a  method  defining  the  steps  needed  to  model  the 
problem  space  in  an  object  oriented  manner.  This  model  provides  a  more  straight¬ 
forward  lead-in  to  Object-Oriented  Design  than  current  function-based  tools  such 
as  data  flow  diagrams,  thus  enabling  a  better  object-oriented  design.  The  method 
also  provides  the  analyst  with  more  guidelines  and  structure  than  the  informal  strat¬ 
egy  of  Booch  [Booch,  1983]  and  Abbott  [Abbott,  1983],  while  still  retaining  a  more 
unstructured  communication  with  the  domain  experts. 

A  more  straightforward  method  of  applying  object  oriented  techniques  in  the 
software  analysis  phase  should  result  in  wider  research  and  application  of  the  object- 
oriented  paradigm.  Additionally,  the  OOA  method  and  tool  could  be  used  to  support 
instruction  in  requirements  analysis,  OOD,  and  the  proper  use  of  Ada  constructs. 

1.6  Sequence  of  Presentation 

The  chapters  of  this  thesis  follow  the  phases  of  research  identifier!  in  the  Ap¬ 
proach  and  Overview  section.  Chapter  II  lays  the  foundation  with  a  review  o!  the 
current  literature  in  the  broad  areas  of  requirements  analysis  and  the  object-oriented 
paradigm.  Chapter  III  identifies  the  requirements,  tools,  and  steps  of  the  Object- 
Oriented  Analysis  method.  Chapter  IV  provides  an  outline  for  a  tool  to  support 
the  analyst  in  applying  the  OOA  method.  Chapter  V  provides  an  evaluation  ot  the 
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method  by  applying  it  to  a  sample  requirements  analysis  problem.  Finally.  Chap¬ 
ter  VI  identifies  conclusions  gathered  from  this  research  and  recommendations  for 
further  study. 
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II.  Literature  Survey 


I  ho  growing  number  of  articles,  books,  and  object-oriented  languages  in  recent 
years  implies  that  the  object-oriented  paradigm  is  more  popular  than  ever.  The  trend 
in  the  literature  also  suggests  an  expansion  of  the  paradigm  from  the  coding  and 
designing  activities  into  the  earlier  activity  of  requirements  analysis.  This  chapter 
begins  by  discussing  the  application  of  object-oriented  techniques  during  the  design 
phase.  It  then  reviews  popular  approaches  to  requirements  analysis  in  order  to 
identify  the  tools  and  methods  used  in  capturing  software  requirements.  The  chapter 
closes  with  a  discussion  of  recent  attempts  to  apply  object-oriented  techniques  to 
requirements  analysis. 

2.1  Object-Oriented  Techniques  in  the  Design  Phase. 

One  of  the  perceived  benefits  of  the  object-oriented  paradigm  is  its  application 
of  modern  software  engineering  principles  to  deal  with  the  complexity  of  large'  proh- 
h'ms.  The  result  is  a  more  natural  mapping  between  the  real  world  problem  (the 
"problem  space")  and  the  solution  represented  by  the  software. 

Other  popular  design  methods  tend  to  carve  the  architecture  of  software  sys¬ 
tems  along  either  functional  or  data-struciure  lines  [Booch,  1 987b: 37 ]  These  meth¬ 
ods  work  fine  when  used  with  older  languages  whose  primary  structuring  mechanism 
is  a  procedure.  However,  these  methods  fail  to  utilize  the  structuring  capabilities 
of  newer  languages,  such  as  the  Ada  package  construct  or  the  object  structure  o! 
Smalltalk,  that  aid  in  the  management  of  complexity  [Booch.  1 987b : 37] .  Pressman 
summarizes  the  promising  aspects  of  object-oriented  design  (OOD): 


I  he  unique  nature  of  object-oriented  design  lies  in  its  ability  to  build 
upon  three  important  software  design  concepts:  abstraction,  information 


hidin'!,  and  modularity.  All  design  methods  strive  for  software  that  ex¬ 
hibits  these  fundamental  characteristics,  but  only  OOD  provid  s  a  mech¬ 
anism  that  enables  the  designer  to  achieve  all  three  without  complexity 
or  compromise.  [Pressman.  1987:3311 

This  section  will  define  ati  object  model  to  be  used  throughout  the  remainder 
of  the  thesis,  and  portray  object-oriented  design  (OOD)  as  it  applies  to  programmin'! 
in  Ada. 

2.1.1  Object  Model.  An  object-oriented  perspective  views  the  world  in  teirn- 
of  objects  and  behaviors.  Work  is  accomplished  when  an  object  sends  a  income 
to  another  object,  asking  it  to  perform  some  behavior.  Kach  object  maintain' 
some  state  information  which  may  be  updated  when  an  object  performs  a  behavior 
'Barnes.  1988:2.13].  The  state  of  higher  level  composite  objects  can  be  describt  d  in 
terms  ot  the  state  of  each  of  its  component  objects. 

The  deli  nit  ions  of  terms  such  as  object  and  behavior  differ  somewhat  amom! 
authors.  I  here  seems  to  be  three  major  reasons  for  the  differences:  the  domain 
of  use  (information  systems  vs  embedded  systems),  the  purpose  of  the  discussion 
(practical  vs  theoretical),  and  the  support  of  the  language  used  to  implement  t  la- 
concept  s. 

In  an  embedded  systems  view  of  OOD.  the  objects  come  primarily  trom  the 
ph vsical  out  it  ies  of  the  problem.  Most  objects  model  the  stale  of  each  of  t  hose  physi¬ 
cal  ent  it  ies.  Ot  her  types  of  systems  take  a  more  liberal  view  of  an  object.  Informal  ion 
systems  oft  hi  expand  the  view  of  an  object  to  entail  relat  ionships  bet  ween  data  item', 
identified  when  thedara  model  is  normalized.  Shlaer  and  Mellor  include  in  their  ob¬ 
ject  definition  any  abstract  concept  in  the  real  world  [Shlaer  and  Mellor.  19VH>7  . 
1  hey  go  so  far  as  to  identify  different  types  of  objects: 

•  Abstractions  of  Itinijihlt  than /.■>  from  the  real  world. 

•  Abstractions  of  m/. ol  entities. 
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•  Abstractions  of  spt  eijicnt  ions  or  ijualitp  criteria. 

•  (  ' olUction s  or  aggregations  of  tangible  items. 

•  Steps  in  the  execution  of  a  process. 

An  object  model  defined  by  Bralick  [Bralick.  lf)SSj  provides  a  more  theoretical 
foundation  for  the  paradigm.  However.  Barnes  identifies  two  weaknesses  in  using 
this  model  in  design.  First,  it  lacks  an  explicit  method  of  describing  the  interac¬ 
tions  o(  objects.  Second,  the  model's  flexibility  in  representing  entities  makes  it  too 
ambiguous  to  provide  a  designer  with  a  clear  path  for  design  [Barnes.  lfl8N:‘J.'J<)  . 
Barnes  defined  an  object  model  aimed  at  the  design  phase,  based  on  the  work  i>v 
Bralii  k  and  a  more  restrictive  model  based  on  Smalltalk  objects. 

Presented  here  is  t lie  object  model  developed  by  Barnes.  Since  the  emphasis 
of  t  his  the  'is  is  toward  object-oriented  concepts  as  applied  toward  the  .Ada  language. 
M  seems  lit  ting  to  also  include  characteristics  of  objects  introduced  bv  (Brady  Booch 
Hooch.  Id'i;  ,  who  applied  the  object-oriented  paradigm  to  development  with  .Ada. 
iog«'t  her.  these  descriptions  will  provide  a  basis  for  b!  >iitifving  the  information  that 
must  be  raptured  during  requirements  analysis. 

J.t.t.l  An  (Abject  Modi  l  for  Design.  Barnes's  object  model  is  charac¬ 
terized  by  objects,  classes  of  objects,  operations,  attributes,  and  relations  among 
object  classes  Barnes.  1  !)N8:2.2oj.  Barm's  summarizes  h's  object  model  in  the  Pil¬ 
lowing  tei  ms: 

•  An  object  is  a  unique  entity  defined  by  attributis  which  serve  to 
identify  the  object  and  relations  which  associate  it  with  other  ob¬ 
jects.  attributes,  and  operations.  Required  attributes  are  name, 
behavior  domain,  and  class.  Relations  include  sets  of  operations, 
components.  a<  tors,  ami  servers. 

•  An  attribute  identifies  an  object  or  operation. 

•  A  nlnt  'oi  represents  an  association  of  an  object  or  operation  with 
other  svstein  objects,  operations,  or  relations. 


•  Aii  operation  is  the  description  of  how  an  object  performs  some 
behavior.  Required  attributes  are  name  and  algorithm.  Relations 
include  sets  of  actors,  servers,  arguments,  and  modified  objects. 

•  A  class  is  a  complete  design  of  an  object  which  may  be  used  as  a 
template  from  which  other  objects  derive  their  characteristic  struc¬ 
ture  and  function.  [Barnes,  1988:3.1] 

In  his  model,  Barnes  distinguishes  between  the  terms  "behavior"  and  "opera¬ 
tion".  lie  defines  a  behavior  as  a  more  informal  description  of  an  object's  functional¬ 
ity  in  response  to  a  stimulus  from  another  object,  while  an  operation  is  a  more  formal 
set  of  algorithms  defining  how  the  behavior  is  performed  [Barnes.  1988:2.21].  Barnes 
also  identifies  the  relationships  between  objects  by  classifying  objects  as  actors  or 
servers,  depending  on  the  direction  the  message  is  passed  [Barnes.  1988:2.251. 

This  object  model  serves  as  a  foundation  for  the  characterist  ics  of  an  object. 
More  specific  aspects  of  the  paradigm  as  implemented  by  Ada  are  considered  by 
including  the  definitions  used  by  Booch. 

2. 1.1.2  Booch's  Characteristics  of  an  Object.  Booch  defines  an  object 
in  general  terms  as  "an  entity  whose  behavior  is  characterized  by  the  actions  that  it 
''lifers  and  that  it  requires  of  other  objects"  [Booch.  1980:21 !  ].  He  goes  on  to  provide 
a  more  detailed  analysis  of  an  object's  characteristics. 

State.  The  state  of  an  object  denotes  the  value  of  the  object  at  a 
point  in  t  ime.  1  his  value  includes  the  st  ate  of  any  sub-objects  contained  in  t  he  object 
m  question  [Booch.  i986:21o].  For  example,  the  state  of  a  windowing  environment 
includes  the  state  of  each  window  running  in  the  environment 

Actions  and  Objects.  An  object  may  require  operat  ions  from  other 
o’:  >  ject  s.  or  it  may  serve  the  requests  of  ot  her  objects.  1  hese  operat  ions  on  an  object 
-<  ■!  ve  to  modi  fv  or  examine  the  state  of  the  oh  ject .  Booch  ident  ifies  t  hree  classes  < >| 
opm  at  ions.  <  Dii.'-/ met  nr  opera  I  ions  modify  t  lie  state  of  an  object .  Se  U  dor  operat  ions 
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examine  the  current  state  of  an  object.  lt(  rat  or  operations  visit  all  sub-component.-, 
of  a  complex  object  in  turn. 

An  object  may  be  classified  by  the  way  it  relates  to  other  objects.  Actor  o\> ject s 
operate  on  others  but  are  not  operated  on.  Server  objects  are  operated  on  by  others, 
but  never  inflict  operations  on  others.  Agent  objects  perform  some  ope-ation  on 
behalf  of  other  objects.  An  agent,  is  both  the  receiver  and  initiator  of  operations 
Hooch.  1986:216]. 

Classes  of  Objects.  A  class  is  a  set  of  unique  objects  that  share 
the  same  characteristics.  Each  object  in  the  class  has  the  same  set  of  operations  as 
other  objects  in  the  class.  A  class  is  characterized  by  a  set  of  values,  and  a  set  of 
operations  applicable  to  objects  of  that  class  [Booch.  1987a:21].  A  system  may  pos¬ 
sess  a  hierarchy  of  classes,  where  a  metaclass  defines  a  set  of  classes;  however.  Ada  s 
support  for  implementing  this  hierarchy  is  somewhat  limited.  [Booch.  1986:216], 

Object  Names.  Names  are  used  to  identify  objects.  Each  ob¬ 
ject  has  at  least  one  name,  and  could  be  referred  to  by  multiple  names  (aliases! 
[Booch.  1986:216], 

Visibility  of  Objects.  Objects  should  be  restricted  in  their  visibil¬ 
ity.  so  that  they  may  collaborate  only  with  other  objects  that  are  logically  required 
to  implement  it's  design.  1  nrestricted  visibility  allows  any  object  to  operate  on  any 
other  object.  Limiting  the  visibility  makes  the  system  more  understandable  and 
modifiable  [Booch.  1986:216]. 

X'ifirs  <,f  Objects.  An  object  may  be  viewed  from  two  different 
perspectives:  inside  or  outside  the  object.  I  lie  outside  view  represents  the  ab  tract 
b  e  h  a  vior  of  an  object  -its  interface  wit  h  >  he  rest  of  I  he  world.  I  he  inside  view  reveals 
the  det  ails  of  how  t  lie  ob  ject  and  its  opera  t  ions  are  implemented  [1  ><  >orh.  1 9*6:2 1  .  j . 
()t  her  objects  otilv  see  the  outside  view  of  an  object . 


2. 1.1.3  Summary.  Together,  Barnes'  object  model  for  design  and  Booth 
characteristics  of  an  object  define  a  framework  for  an  Ada  view  of  the  object-oriented 
paradigm.  This  model  also  serves  as  a  starting  point  for  identifying  the  information 
that  must  be  captured  during  software  requirements  analysis.  The  next  section  dis¬ 
cusses  the  object-oriented  design  method  proposed  for  Ada  by  Grady  Booch. 

2.1.2  Object-Oriented  Design  (00D).  The  foundations  of  applying  the  object 
oriented  paradigm  to  the  design  phase  date  back  at  least  as  far  as  Parnas’  discus¬ 
sion  of  information  hiding  [Parnas,  1972],  However,  it  wasn’t  until  the  develop¬ 
ment  of  Ada  and  object  oriented  languages  that  interest  mounted  in  applying  the 
paradigm  in  the  design  phase.  All  languages  are  object-oriented  to  some  degree 
[FA  B,  1985,  Bralick,  1988:2.2].  However,  it  is  a  language’s  support  for  data  abstrac¬ 
tion,  information  hiding,  and  to  a  lesser  extent  dynamic  binding  and  inheritance 
that  makes  it  suitable  for  object-oriented  programming  [Pascoe  1986:1 10].  Although 
Ada  is  weak  in  the  areas  of  dynamic  binding  and  inheritance  [Pascoe,  1986:142],  it 
strongly  supports  the  concepts  of  abstraction  and  information  hiding,  making  it 
suitable  for  implementing  an  object-oriented  design  [Booch.  1986:216], 

2. 1.2.1  Booch's  Object-Oriented  Design  \fethod.  The  version  of  object- 
oriented  design  (OOD)  made  popular  by  Grady  Booch  [Booch.  1983]  relies  on  the 
research  of  Russell  Abbott.  Abbott's  approach  to  software  design  began  with  the 
development  of  a  textual  “informal  strategy"  [Abbott.  1983],  Booch  applied  this 
approach  in  an  object-oriented  framework  to  develop  his  initial  version  of  OOD. 

''Traditional  OOD.  Booch's  initial  version  of  OOD  involved  the 
following  steps  [Booch.  1983,  EYB.  1985,  Pressman.  1987]: 

1  )  Dijine  the  problem.  1  he  use  of  analysis  tools  is  appropriate  at  this 
point  to  define  the  problem  space  [Booch.  198.3:11],  Some  advocates 


recommend  stating  the  underlying  problem  in  a  single,  grammati¬ 
cally  correct  sentence  [EVB,  1985,  Pressman.  1987). 

2)  Develop  an  Informal  Strategy.  English  prose  is  used  to  define  a  solu¬ 
tion  using  the  terms  of  the  problem  space  [Booch,  1983:42],  This  in¬ 
formal  strategy  specifies  the  relationships  among  objects  that  make 
up  the  solution  (EVB,  1985:1.4]. 

3)  Formalize  the  Strategy.  This  step  involves  four  sub-steps.  First 
objects  and  their  attributes  are  identified  from  the  nouns  and  noun 
phrases  in  the  informal  strategy.  Next,  operations  on  the  objects  are 
identified  from  the  verbs  and  verb  phrases  in  the  informal  strategy. 
Third,  interfaces  between  objects  are  established,  and  expressed  in 
a  graphical  notation  (see  the  example  in  figure  2.1).  Finally,  the 
operations  are  implemented,  potentially  applying  the  OOD  process 
recursively  on  the  operations.  [Booch,  1983:42-43] 

Booch  and  his  followers  have  since  modified  their  approach  somewhat,  resulting 
in  less  of  a  dependence  on  an  informal  strategy  to  identify  objects  and  operations. 

“ Contemporary ”  OOD.  The  steps  in  this  “contemporary"  ap¬ 
proach  to  OOD  are  listed  below  [Booch,  1986,  Booch,  1987a,  Booch.  1987b]: 

1)  Identify  the  objects  and  their  attributes.  Although  nouns  used  to 
describe  the  problem  space  are  mentioned  as  a  possible  guideline  to 
identifying  objects,  no  mention  is  made  of  developing  an  informal 
st ratcgy[Booch,  1 987b : 48] . 

2)  Identify  the  operations.  This  step  characterizes  the  behavior  of  each 
object  or  class  by  identifying  the  operations  that  affect  each  object 
or  class  and  the  operat  ions  that  each  must  initiate  [Booch.  1987b:48- 
19], 

3)  Establish  the  visibility  of  each  object.  The  static  visibility  of  each 
object  is  defined  in  relation  to  other  objects  in  the  system,  using 
t lie  graphical  notation  identified  earlier  [Booch.  19S7b:49]. 

1  )  Establish  the  interface  of  each  object,  t  he  interface  of  each  object 
or  class  is  specified  using  some  suitable  notation,  such  as  an  Ada 
package  specification.  This  interface  is  the  view  of  the  object  or 
class  to  other  objects  in  the  software  system  [Booch.  1987b: !!)]. 


5)  Implement  each  object.  Each  object  is  implemented  using  a 
suitable  language  feature.  The  object  may  be  further  decom¬ 
posed  by  recursively  reapplying  the  00D  process,  or  composed 
in  a  bottom-up  fashion  from  existing  lower-level  objects  or  classes 
[Booch,  1987b:49] . 

This  version  of  OOD  minimizes  the  emphasis  on  the  informal  strategy  and. 
instead,  emphasizes  the  use  of  traditional  analysis  tools  to  define  the  problem 
[Booch,  1986.  Booch,  1987b,  Booch,  1987a:47],  Ladden  summarizes  reasons  for  the 
shift  away  from  the  informal  strategy  approach  to  OOD: 

The  viability  of  the  well-known  technique  of  developing  an  'informal 
strategy’  by  creating  a  narrative  description  of  the  problem,  and  then 
selecting  the  objects,  operations  and  attributes  of  the  system  from  the 
nouns,  verbs,  adjectives,  and  adverbs  of  this  narrative  description  is 
questioned.  It  inherently  lacks  rigor  due  to  the  impreciseness  of  the 
English  language;  the  approach  appears  to  have  been  disregarded  by 
its  originator;  and  its  suitability  for  large  projects  has  been  criticized. 
[Ladden,  1989:87] 

Object-Oriented  Design  as  known  today  is  not  a  full  life  cycle  method 
[Booch.  1986:84],  OOD  assumes  that  the  problem  space  has  been  previously  defined 
and  organized  using  some  form  of  analysis  tools.  Two  approaches  to  this  analysis 
are  possible.  A  traditional  analysis  method  may  be  applied  to  the  problem  and  then 
translated  into  an  object-oriented  representation.  An  alternative  is  to  use  object- 
oriented  techniques  throughout  the  life  cycle  [EVB,  1989:15],  Both  approaches  will 
be  considered  in  the  last  section  of  this  chapter. 

As  defined  in  chapter  I.  the  primary  goal  of  this  thesis  is  to  develop  an  object- 
oriented  approach  to  the  analysis  phase.  This  object-oriented  requirements  analysis 
/OORA)  activity  will  precede  the  OOD  process  to  achieve  a  more  complete  file 
cycle  met  hodology.  The  development  of  this  Object-Oriented  Requirements  Analysi- 
method  assumes  than  an  object-oriented  approach  si  in  i  1  a  r  to  the  “contemporary" 
OOD  approach  will  be  used  during  the  design  phase. 


2. 2  The  Definition  Phase 

As  mentioned  at  the  outset  of  this  chapter,  the  object-oriented  paradigm  seems 
to  be  working  its  way  backward  in  the  life  cycle.  Whereas  object-oriented  techniques 
have  been  practiced  in  the  development  phase  for  nearly  a  decade  (an  eon  in  the 
rapidly  advancing  computer  field!),  application  of  the  paradigm  in  the  requirements 
analysis  phase  is  a  much  more  recent  phenomenon.  This  section  identifies  current 
approaches  to  delineating  requirements  for  software  systems,  presenting  a  menu  of 
alternative  representations  on  which  an  object-oriented  approach  may  be  based. 

2.2.1  Software  Requirements  Analysis.  The  IEEE  defines  requirements 
analysis  as  ;‘the  process  of  studying  user  needs  to  arrive  at  a  definition  of  system  or 
software  requirements”  [IEEE,  1983:30],  Software  requirements  analysis  is  therefore 
concerned  with  studying  user  needs  to  be  able  to  define  software  requirements. 

Yalusek  makes  a  useful  distinction  between  requirements  analysis  and  require¬ 
ments  determination.  Requirements  determination  is  a  user-oriented  process  of  de¬ 
veloping  a  list  of  candidate  requirements.  Requirements  analysis  is  the  later  process 
of  focusing  ami  reconciling  these  possibly  conflicting  requirements,  and  detailing 
them  in  a  specification  [Valusek  and  Fryback.  1987:117]. 

Land  identifies  four  common  techniques  of  identifying  requirements.  An  ana¬ 
lyst  may  interview  users,  carry  out  surveys,  observe  the  system  or  organization  in 
operation,  or  study  documentation  of  the  current  system  [Land,  et  al..  1987:208]. 
Prototyping  can  also  be  included  in  this  incomplete  list  of  methods  used  to  identify 
the  requirements  of  a  software  system  [Gomaa  and  Scott.  1981], 

I  he  output  of  the  software  requirements  analysis  activity  is  a  model  ol  the 
problem  space.  I  his  model  serves  a  number  of  purposes.  The  model 

•  specifies  the  logical  requirements  without  detailing  a  physical  im¬ 
plementation  [Gann  and  Sarson.  1982:9], 
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•  expresses  preferences  and  trade-offs  of  potential  approaches 
[Cane  and  Sarson,  1982:9]. 

•  focuses  attention  on  important  features  of  the  system  while  de¬ 
emphasizing  less  important  features  [Yourdon,  1989:65]. 

•  presents  a  basis  for  discussion  with  the  user  about  changes  or  cor¬ 
rections  to  the  system  [Yourdon,  1989:65], 

•  verifies  that  the  analyst  correctly  understands  the  user’s  problem 
[Yourdon,  1989:65]. 

•  documents  the  system  so  that  designers  and  programmers  can  build 
it  [Yourdon,  1989:65]. 


2.2.2  Information  Captured  During  Analysis.  The  literature  identifies  a  mul¬ 
titude  of  elements  to  include  in  a  model  of  the  software  requirements.  These  elements 
are  summarized  below. 


•  Information  Domain.  This  consists  of  the  flow,  content,  and  struc¬ 
ture  of  data.  The  information  flow  describes  the  manner  in  which 
data  changes  as  it  flows  throughout  the  system.  The  information 
content  represents  the  individual  data  items  in  the  system.  Infor 
mation  structure  describes  how  these  data  items  are  grouped  into 
more  complex  data  structures  [Yourdon.  1989,  Pressman,  1987:1  12]. 

•  Functional  Elements.  A  description  of  the  functions  the  sys¬ 
tem  is  to  perform  is  included  [Yourdon,  1989.  Yadav,  et,  al..  1988. 
Land,  et  ah,  1987,  Pressman,  1987:21]. 

•  Interface  Characteristics.  The  links  between  the  system  and 
the  outside  world  are  identified  and  described  [Yadav,  et  ah,  1988. 
Pressman,  1987:47],  This  may  also  include  the  existence  and  fre¬ 
quency  of  any  external  events  that  the  system  must  respond  to 
[Peters.  1987.  McMenamin  and  Palmer.  1981:38], 

•  Design  Constraints.  Any  constraints  on  the  design  of  the 
system,  including  performance  requirements  [Yadav.  et  ah,  1988. 
Pressman.  1987:21],  or  '‘metarequirement s"  (design  decisions  made 
up  front  by  the  user)  [EVB,  1989:31]. 


2.2.2  Requirements  Analysis  Tools.  Many  different  people  use  t he  model  de¬ 
veloped  during  software  requirements  analysis,  including  users,  designers,  coders. 


2-11 


project  managers,  and  maintainers.  Therefore,  the  model  must  promote  compre¬ 
hension  and  communication  among  these  parties  [Jorgensen.  1986:182].  A  number 
of  tools  are  used  to  portray  the  information  described  in  the  previous  section  in 
an  understandable  manner.  Each  tool  focuses  on  a  diiferent  aspect  of  the  system. 
Therefore,  combinations  of  these  tools  are  required  to  fully  describe  the  software 
requirements.  Some  of  the  more  common  and  useful  tools  are  listed  below. 

2.2.3. 1  Data  Flow  Diagram.  The  data  flow  diagram  (DFD)  reveals  the 
processes  in  a  system  and  the  data  flows  between  them.  A  DFD  is  made  up  of  circles 
representing  processes,  arcs  portraying  data  flows,  straight  lines  illustrating  stores 
of  data,  and  boxes  depicting  external  sources  or  sinks  of  data  [DeMarco.  1979:51]. 
An  example  data  flow  diagram  is  displayed  in  figure  2.2. 

Data  flow  diagrams  may  represent  different  levels  of  abstraction  of  a  sys¬ 
tem.  Each  of  the  processes  in  figure  2.2  may  be  broken  down  and  represented 
with  its  own  DFD.  This  concept  is  known  as  the  leveling  of  data  flow  diagrams 
[DeMarco,  1979:72], 

2. 2.3. 2  Data  Dictionary.  The  data  dictionary  is  an  organized,  textual 
listing  of  the  data  items  relevant  to  the  system,  containing  a  precise  definition  of 
each  of  the  items  [Yourdon,  1989:189],  The  data  dictionary  is  often  used  to  support 
a  DFD  by  defining  the  data  flows  and  stores  identified  by  the  diagram.  The  contents 
of  a  data  dictionary  may  varv  with  use.  Clane  and  Sarson  [Gane  and  Sarson.  1982:76] 
include  the  following  fields: 

•  A  definition  of  the  data  item. 

•  Other  related  data  elements. 

•  The  range  of  values  and  meanings  of  values  for  the  data  element. 

•  1  he  length  of  the  element. 

•  Any  encoding  used  for  the  data. 

•  Other  editing  information. 
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Figure  2.2.  Data  Flow  Diagram  [Yourdon.  1  f>SD :  1  1 1  ] 
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Figure  2.3.  State  Transition  Diagram  of  a  Process 

2. 2. 3. 3  State  Transition  Diagram.  A  state  transition  diagram  (STD)  is 
used  to  capture  the  time-dependant  behavior  of  a  system  [Yourdon.  1989:259],  One 
common  notation  uses  circles  to  denote  each  possible  state  of  the  system,  and  arcs 
to  represent  transitions  between  the  states.  Labels  on  the  arcs  state  the  condition(s) 
required  for  the  state  transition  [EVB,  1989:163].  Figure  2.3  is  an  example  of  a  state' 
transition  diagram  of  a  process  in  a  simple  operating  system. 

2. 2. 2. 4  Entity  Relationship  Diagram.  The  entity  relationship  diagram 
(FBI))  was  originally  proposed  by  Chen  as  a  tool  for  database  design  [Chen.  1976:9], 
(lie  diagram  captures  semantic  information  about  the  real  world  in  terms  ol 
entities,  or  "filings",  from  the  real  world  arid  the  relationships  between  them. 
Analysts  use  the  diagrams  to  describe  the  layout  of  data  stores  in  a  system 
[Martin  and  McClure.  1985,  Yourdon.  1989:233],  The  basic  notation  of  an  ER1)  in¬ 


cludes  rectangles  to  denote  entities  and  diamonds  to  show  the  relationships  between 
them.  An  example  ERD  is  shown  in  figure  2.1.  There  are  various  forms  of  entity 


Figure  2.4.  Entity  Relationship  Diagram  (ERD)  [Yourdon,  1089:235] 


relationship  diagrams,  varying  mainly  in  the  information  included  about  the  relation¬ 
ships.  For  example,  a  one-to-manv  relationship  may  be  shown  with  an  arrowhead  on 
the  arc  (as  in  figure  2.4),  or  with  ‘1’  and  'M'  on  ends  of  the  arc  [Yourdon.  1980:210], 

2.2. 3. 5  Concept  Map.  The  concept  map  is  not  a  traditional  tool  for 
requirements  analysis.  Instead,  it  was  developed  by  Novak  and  Cowin  as  an  edu¬ 
cational  tool  to  summarize  understanding  of  a  topic  [Novak  and  Gowin,  1984].  1  lie 
concept  map  is  similar  to  an  entity  relationship  diagram  in  that  it  identifies  impor¬ 
tant  entities  or  concepts  about  a  topic  and  describes  the  relationships  between  them. 
I  lie  notation  used  in  concept  maps  is  modest.  Ovals  are  used  to  denote  core  <  pts. 
while  labeled  edges  identify  the  relationships.  This  simple,  unstructured  notation 
makes  the  concept  map  easy  to  apply  and  understand. 

Me Farren  has  proposed  t  he  use  of  concept  maps  as  an  aid  to  developing  decision 
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Figure  2.5.  Concept  Map  of  "Concept  Maps" 

support  systems  (DSS).  The  concept  map  helps  the  decision  maker  communicate  his 
understanding  of  the  problem  to  others,  and  provides  a  medium  for  identifying  any 
misconceptions  held  by  the  DSS  builders  [McFarren,  10871.  flames  [Barnes.  I  OSS 
and  Cmphress  [Cmphress.  1 988 j  have  built  on  this  idea,  proposing  t  he  use  of  concept 
maps  as  a  tool  for  modeling  the  problem  space  during  soffware  requirements  analysis. 
Barnes  maintains  the  concept  map  is  more  descriptive  than  the  informal  strategy 
of  GOD.  allowing  a  more  direct  means  of  identifying  the  objects  arid  operations  of 
the  problem  space  [Barnes.  1988:0..'?].  Barnes’  proposed  methodology  for  a  full  life 
(  \  c]e  object-oriented  methodology,  including  the  use  of  concept  maps,  is  described 
in  'cct  ion  J.5.  1 .2. 

Figure  2.5  is  an  example  of  a  concept  map  describing  the  essence  of  concept 
maps  that  are  important  to  this  thesis. 
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J.J.  i.6  Summary.  I  he  set  of  tools  described  above  is  by  no  means 
complete.  I  he  tools  presented  are  those  which  are  widely  used,  or,  in  the  case  of 
the  concept  map.  show  potential  for  use  in  the  requirements  analysis  phase.  Some 
combination  of  the  tools  described  above  can  be  used  to  represent  the  majority  of 
the  elements  in  the  requirements  model  defined  in  section  2.2.2.  English  prose  nny 
atld  to  or  support  the  information  presented  in  the  diagrams.  However,  it  is  difficult 
to  define  a  complex  system  concisely  and  unambiguously  with  a  natural  language 
alone  [Martin  and  McClure.  1985.  Yourdon.  1989,  Ross  and  Schoman.  1977:9], 

2.2..j  Approaches  to  Software  Requirements  Analysis.  The  selection  and  ap¬ 
plication  of  these  tools  depends  on  the  approach  taken  toward  requirements  analysis. 
Pressman  claims  that  all  requirements  analysis  methods  are  related  by  similar  un¬ 
derlying  principles.  In  any  analysis  method,  the  following  activities  occur: 

•  I  he  information  and  functional  domains  of  the  problem  must  be 
represented  and  understood  by  the  analyst. 

•  file  problem  is  partitioned  such  that  detail  is  uncovered  in  a  layered 
fashion. 

•  Logical  and  physical  models  of  the  system  are  developed. 
[Pressman.  1987:141-1  12] 

Requirements  analysis  methods  differ  mainly  in  the  way  the  problem  is  parti¬ 
tioned.  Systems  may  be  expressed  in  terms  of  data  flow  between  system  functions, 
data  structures,  events  and  responses,  or  objects.  While  specific  analysis  methods 
may  use  multiple  tools  to  capture  different,  views  of  the  system,  one  of  the  views 
typically  predominates  over  the  others.  Methods  can  therefore  be  categorized  by 
their  approach  to  requirements  analysis. 

J.J.fl  Data  Now  One  n/i  il  Analysis.  Not  surpnsinglv.  requirement' 
analysis  based  on  data  flow  makes  heavv  use  of  the  data  How  diagram.  1  he  sV'tem 


is  broken  up  into  the  major  functions  required  of  the  software.  Each  of  these  major 
functions  is.  in  turn,  broken  down  into  its  subfunctions  until  the  system  is  expressed 
in  terms  of  primitive  processes. 

DeMarco's  Structured  Analysis  is  an  example  of  a  data  flow  oriented  analysis 
method.  The  major  steps  in  his  method  are: 


L)  Study  the  current  physical  environment  and  document  it  in  a  Cur¬ 
rent  Physical  Data  Flow  Diagram. 

2)  Derive  the  logical  equivalent  of  the  current  environment,  and  de¬ 
velop  a  Current  Logical  Data  Flow  Diagram. 

■i )  Derive  the  new  logical  environment,  as  portrayed  in  the  New  Logical 
Data  Flow  Diagram  plus  supporting  documentation. 

4)  Determine  physical  characteristics  of  the  new  environment,  and  pro¬ 
duce  a  set  of  tentative  New  Physical  Data  Flow  Diagrams. 

•5)  Quantify  cost  and  schedule  data  associated  with  each  of  the  possi¬ 
bilities  represented  by  the  set  of  New  Physical  Data  Flow  Diagrams. 

6)  Select  one  option,  represented  by  one  New  Physical  Data  Flow  Di¬ 
agram. 

7)  Package  the  New  Physical  Data  Flow  Diagram  and  supporting  doc¬ 
uments  into  the  Structured  Specification.  [DeMarco.  1979:27] 


DeMarco's  approach  has  come  under  criticism  recently  for  the  amount  of  time 
spent  documenting  the  old  system.  This  realization  has  caused  a  trend  toward  start¬ 
ing  with  a  model  of  the  proposed  system  and  eliminating  the  formal  documentation 
of  i  lie  exist  ing  system  [Coad.  198.8.  Yourdon.  1989:125]. 


2.2.  /. 2  Erent-Rrsponsr  Based  Analysis.  The  event -response  approach 
i"  characterized  by  t'm  identification  of  external  stimuli  to  which  the  system  must 
respond  [Coad.  1988.  Shlaer  and  Mellor.  1988],  These  events  are  used  as  a  starting 
point  lor  organizing  the  analysis  of  the  system. 

I  he  event  .response  approach  results  in  the  development  of  the  "essential 
modi  1  of  the  system  [McMenamin  and  Palmer.  1981.  Yourdon.  198!)].  According 
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to  \ourdon.  the  essential  model  is  composed  of  an  environment  model  which  defines 
the  boundary  between  the  system  and  the  outside  world,  and  a  behavior  model  which 
provides  a  view  of  the  insides  of  the  system  [Yourdon,  1989:326], 

Development  of  the  environment  model  consists  of  defining  a  statement  of  pur¬ 
pose,  a  context  diagram,  and  an  event  list.  The  statement  of  purpose  is  a  short  (single 
paragraph)  description  of  the  purpose  of  the  system,  aimed  mainly  toward  manage¬ 
ment.  1  he  context  diagram  views  the  system  as  a  single  bubble  in  a  data  flow  dia¬ 
gram.  and  documents  its  connections  to  the  outside  world.  The  event  list  is  a  list  ol 
externally  generated  signals  to  which  the  system  must  respond  [Yourdon,  1989:337- 
311], 

After  the  environment  model  is  defined,  attention  turns  to  the  development 
of  the  behavior  model.  At  this  point,  a  data  flow  diagram  is  developed  based  on 
the  external  events  identified  in  the  environment  model.  A  bubble  is  drawn  for  each 
event  in  the  event  list,  and  named  with  the  corresponding  response  to  that  event. 
Inputs,  outputs,  and  data  stores  are  drawn  as  needed  to  represent  communication 
between  the  bubbles.  This  first-cut  DFD  is  then  layered  both  up  and  down;  bubbles 
are  combined  to  arrive  at  a  DFD  at  a  level  above  the  first  rut  DFD.  and  exploded 
to  develop  lower  level  DFDs.  An  entity  relationship  diagram  is  usually  developed 
in  parallel  to  document  the  information  structure  of  the  system  [Yourdon.  1989:300- 
365]. 


2.J../.J  Data  Structure  Oriental  Analysis.  As  its  name  implies,  data 
structure  oriented  analysis  specifies  software  requirements  by  focusing  on  the  data 
structure  of  a  problem  instead  of  the  data  flow.  The  system  is  therefore  modeled 
according  to  an  information  structure  of  the  problem  [Pressman.  1987:209], 

Data  structure  approaches  share  a  number  of  charactenst  ics.  First,  key  data 
items  and  processes  are  identified.  Second,  the  structure  of  information  is  assumed 
to  lie  hierarchical.  Third,  data  structures  are  represented  as  eitlie  a  sequence  of 
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data  items,  a  repeated  grouping  of  data  items,  or  as  a  selection  from  among  a  set 
of  data  items.  Finally,  a  set  of  steps  are  defined  for  mapping  the  hierarchical  data 
structure  into  the  structure  of  the  program  [Pressman,  1987:172]. 

2. 2. 4  Object-Oriented  Analysis.  The  final  approach  to  software  re¬ 
quirements  analysis  is  the  object-oriented  approach.  This  is  the  newest  and  least 
defined  approach  to  analysis.  There  is  general  agreement  in  the  sense  that  the  over¬ 
all  goal  is  to  identify  objects  from  the  real  world  in  terms  of  the  data  and  operations 
that  compose  them.  The  manner  in  which  a  system  model  should  be  organized  in 
terms  of  these  objects  is  still  open  to  debate.  Some  specific  approaches  are  discussed 
in  section  2.3. 

2.2.5  Summary.  This  section  has  identified  some  of  the  current  tools  and 
approaches  used  in  the  analysis  of  software  requirements.  Each  approach  models,  in 
some  fashion,  the  information  domain,  functional  elements,  and  interface  character¬ 
istics  of  the  problem.  The  approaches  differ  in  their  choice  of  the  characteristic(s) 
to  serve  as  the  basis  for  the  model  of  the  system. 

2.2  Object-Oriented  System  Models 

There  are  currently  two  different  approaches  to  the  development  of  object- 
oriented  models  of  software  systems.  The  first  approach  applies  either  data  flow, 
event-response,  or  data  structure  oriented  requirement  analysis  methods  to  model 
tin  system.  This  model  is  then  transformed  into  a  specification  which  models  tin1 
system  in  terms  of  objects  and  operations.  The  alternative  approach  is  to  replace 
tin1  more  traditional  approaches  to  analysis  with  an  object-oriented  strategy  Irom 
the  beginning  [EYB.  1989.  Ward.  1989:71], 

i.l.l  Translating  Traditional  Models.  Ward  claims  that  there  is  no  funda¬ 
mental  opposition  between  certain  fund  ion-oriented  analysis  techniques  (with  ex- 
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tensions)  and  object-oriented  design  {Ward,  1989:82].  Ladden  agrees  that  at  least 
some  of  the  principles  of  the  two  methods  are  complementary  [Ladden,  1989:78], 
and  suggests  that  the  major  difference  is  in  the  order  of  applying  certain  analysis 
activities.  The  traditional  approach  to  analysis  is  to  first  define  the  functional  ele¬ 
ments  and  then  "package”,  or  group,  similar  functior  .  .ogether.  An  object-oriented 
approach  first  identifies  the  packages,  or  objects,  and  then  identifies  the  functional 
elements  associated  with  each  object  [Ladden,  1989:82]. 

2. 3.1.1  Abstraction  Analysis.  Seidewitz  and  Stark  have  proposed  a 
method  for  translating  a  data  flow  oriented  requirements  specification  into  an  object- 
oriented  design  [Seidewitz  and  Stark,  1986,  Seidewitz  and  Stark.  1987],  Their 
method,  which  they  term  abstraction  analysis,  uses  data  flow  diagrams  as  a  basis 
for  identifying  abstract  entities  and  an  initial  control  hierarchy.  Objects,  operations, 
and  a  virtual  machine  hierarchy  are  then  identified  [Seidewitz  and  Stark.  1986:5.1]. 
The  steps  involved  in  transform  analysis,  taken  from  [Seidewitz  and  Stark.  19871. 
are 

1)  Identify  the  central  entity  from  the  data  flow  diagram.  This  central 
entity  is  the  best  abstraction  of  what  the  system  will  do. 

2)  Moving  away  from  the  central  entity  along  data  flows  on  the  DFD, 
identify  the  entities  that  directly  support  the  central  entity. 

3)  Construct  an  entity  graph  depicting  the  flow  of  control  between 
entities.  The  entity  graph  shows  the  interconnection  of  abstract 
entities  in  the  problem  domain  from  a  control  point  of  view.  The 
graph  serves  as  the  basis  for  identifying  objects. 

1)  Develop  an  object  diagram  from  the  entity  graph.  The  object  dia¬ 
gram  is  based  on  the  central  entities  and  objects  of  the  entity  graph. 

I  he  diagram  (sec  figure  2.6)  delineates  objects  and  t  heir  required 
access  of  other  objects. 

•5)  Identify  operations  provided  to  and  used  by  the  objects. 

6)  Repeat,  the  above  process  on  lower  level  DFDs.  This  will  identify 
subordinate  objects  to  those  already  identified. 


7)  Translate  the  object  diagrams  into  an  object-oriented  design  in  Ada. 

[Seidewitz  and  Stark,  1987:4.60-4.64]. 

Ladden  has  identified  some  difficulties  in  identifying  objects  from  DFDs.  When 
DFDs  are  used  together  with  traditional  structured  design,  there  is  usually  a  one- 
to-one  mapping  between  bubbles  on  the  DFD  and  software  modules  at  the  higher 
levels  of  design  [Ladden,  1989:84],  However,  when  identifying  objects  from  DFDs. 
the  relationship  between  process  bubbles  and  objects  may  not  be  as  evident.  Objects 
may  overlap  more  than  one  DFD,  more  than  one  object  may  be  identified  from  a 
single  level  of  a  DFD,  and  even  single  bubbles  of  the  DFD  may  be  allocated  to 
more  than  one  object.  Another  difficulty  is  in  associating  the  data  stores,  flows  and 
processes  of  a  DFD  with  objects.  This  may  require  either  grouping  a  number  of  DFDs 
together,  or  redrawing  the  DFDs  with  redundant  components  [Ladden.  1989:80], 
According  to  Kenth,  Seidewitz  himself  has  admitted  that  it  is  difficult  to  get  an 
object-oriented  design  from  a  specification  constructed  without  consideration  of  the 
object-oriented  paradigm  [Kenth,  et  al.,  1987:11], 

2.3. 1.2  Alternative  Methods.  One  suggested  alternative  method  of 
identifying  the  objects  in  the  model  is  to  supplement  DFDs  with  other  tools,  such  as 
the  entity  relationship  diagram  (ERD).  Seidewitz.  Ladden.  and  Ward  all  suggest  the 
use  of  the  ERD  as  a  means  of  identifying  the  objects  for  the  model.  The  information 
from  the  ERD  is  supplemented  with  a  stimulus-response  analysis  [Ward.  1989:7!)] 
or  DFDs  [Kenth.  et  al.,  1987,  Ladden.  1989:81]  to  define  a  more  complete  system 
model. 

A  method  defined  bv  Barnes  uses  the  concept  map  to  organize  the  informa¬ 
tion  contained  in  the  models  of  traditional  analysis  methods.  Barnes  proposes  the 
development  of  multiple  concept  maps  from  the  requirements  specificat ion  and  user 
interviews.  These  concept  maps  are  then  synthesized  into  a  single  sentence  state¬ 
ment  of  the  problem,  and  a  single  concept  map  depicting  a  solution  strategy.  1  his 
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igure  2.6.  Object  Diagram  of  a  Desk  Top  Schedule  Organizer 
[Seidewitz  and  Stark.  1987:1.56] 


single  concept  map  serves  as  the  basis  for  identifying  the  objects,  attributes,  and 
operations  needed  in  the  solution  [Barnes,  1988:3.6], 

2.3. 2  “True”  Object-Oriented  Approaches.  The  alternative  to  translating  a 
function-oriented  specification  into  an  object-oriented  design  is  to  use  object-oriented 
techniques  from  the  outset  of  requirements  analysis.  The  benefits  of  the  object- 
oriented  paradigm  may  be  magnified  with  their  earlier  application  [EYB.  1989], 

2.3.2. 1  Coad's  Framework  for  Object-Oriented  Requirements  Analysis. 
As  stated  in  section  2. 2. 4. 4,  the  object-oriented  approach  to  software  requirements 
analysis  has  not  reached  a  consensus  in  its  specific  steps.  One  framework  proposed 
by  Coad  is  to  represent  the  system  in  terms  of  object,  attribute,  and  process  layers. 
I  he  object  layer  identifies  potential  objects  and  their  relationships.  The  attribute 
layer  defines  descriptive  and  identification  attributes  about  the  objects.  The  process 
layer  defines  responses  of  each  object  to  external  events,  and  the  data  flows  between 
objects  [Coad,  1988],  The  example  in  figure  2.7  shows  the  relationships  between 
objects  at  these  layers. 

2.3. 2.2  Shlaer  and  Mellor's  Object-Oriented  Domain  Analysis.  Shiner 
and  Mellor  have  recently  proposed  an  approach  to  object-oriented  analysis  based  on 
information,  state,  and  process  models  [Shlaer  and  Mellor.  1989:66].  Together,  these 
models  represent  the  system  requirements.  The  general  elements  in  their  approach 
a  re: 

1 .  Information  Models.  A  detailed  version  of  Chen's  entity  relationship 
diagram  is  used  to  identify  the  objects,  attributes  and  relationships 
of  the  problem.  (See  the  portion  of  an  information  model  of  a  juice' 
factory  in  figure  2.8. 

2.  Stall  Models.  The  life1 2  cycles  of  the  objects  are  expressed  using  state' 
transition  diagrams. 


3.  Process  .\fodels.  The  state  transition  diagram  is  used  to  identify  the 
processes  required  to  drive  an  object  through  its  life  cycle.  Data 
flow  diagrams  are  used  to  depict  the  action  processes  for  each  state 
in  the  state  model. 

4.  Boundary  Statement.  The  external  boundary  of  the  automated  por¬ 
tion  ot  tfie  system  is  identitied. 

Shlaer  and  Mellor  recognize  the  relationship  between  the  nature  of  an  object 
(as  actor,  agent,  or  server)  and  it's  location  in  the  system  hierarchy.  Those  ob¬ 
jects  at  the  upper  level  of  abstraction  tend  to  be  actors  sending  messages  to  guide 
lower  level  objects  through  their  life  cycles.  Objects  in  the  middle  levels  are  usu¬ 
ally  agents,  receiving  messages  from  the  upper  level  objects,  and  requesting  opera¬ 
tions  from  the  lowest  level  objects.  The  objects  at  the  lowest  level  of  abstraction 
are  often  unintelligent  servers,  typically  used  to  directly  model  a  hardware  entity 
[Shlaer  and  Mellor,  1989:74-75], 

2. 3. 2. 3  Bailin's  Object-Oriented  Requirements  Specification  Method. 
Sidney  Bailin  proposes  another  new  method  of  transforming  a  textual  requirements 
statement  into  a  more  formal,  graphical  model.  His  method  uses  both  a  set  of  en¬ 
tity  relationship  diagrams  and  a  hierarchy  of  entity  data  flow  diagrams  (EDFDs)  to 
capture  the  system  requirements.  An  EDFD  is  similar  to  a  traditional  DFD.  except 
that  the  nodes  may  be  entities  as  well  as  functions  [Bailin,  1989:609],  Each  function 
is  performed  in  the  context  of  some  entity. 

The  steps  in  producing  the  specification  are  described  below: 


1.  Identify  hey  problem-domain  entities.  An  entity  relationship  dia¬ 
gram  is  used  to  record  the  problem  domain  entities  and  their  inter¬ 
relationships. 

2.  Distinguish  between  active  and  passive  entities.  Intuitively,  active 
entities  act  as  processes,  while  passive  entities  are  data  flows.  Bailin 
revises  t  his  definit  ion  to  consider  active  ent  it  ies  as  t  hose  whose  func- 
tions  are  important  to  consider  during  requirements  analysis.  A 
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•’2.8.  Shlaer  and  Mellor's  Information  Model  of  a  Juice  Factory  (partial) 
[Shlaer  and  Mellor.  1989:69] 


passive  entity  is  then  one  whose  functions  need  not  be  considered 
until  the  design  phase. 

3.  Establish  data  flow  between  active  entities.  Entity  data  flow  dia¬ 
grams  document  this  flow.  Each  active  entity  in  the  ERD  becomes 
a  process  in  the  EDFD.  Passive  entities  appear  as  data  stores,  or  as 
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t.  Decompose  entities  (or  functions)  into  sub-entities  and/or  func¬ 
tions.  These  next  three  steps  form  the  heart  of  the  method.  In  this 
step,  the  EDED  is  decomposed  into  subentities  and/or  functions  in 
a  new  EDFD.  Subentities  compose  the  entity,  while  a  function  is 
performed  by  the  entity. 

5.  Chech  for  new  entities.  The  new  EDFDs  are  scanned  to  coo  if  they 
imply  the  existence  of  new  entities.  These  new  entities,  if  significant, 
should  then  be  included  in  the  entity  relationship  model. 

6.  Group  functions  under  new  entities.  For  each  of  the  new  entities 
introduced  in  the  previous  step,  the  functions  performed  by  or  on  the 
new  entities  are  identified,  dieting  functions  may  be  rearranged  to 
fall  under  one  of  the  new  entities.  The  goal  of  this  step  is  to  identify 
the  functions  to  ensure  that  the  entity  is  functionally  complete. 

7.  Assign  new  entities  to  appropriate  domains.  Finally,  the  new  enti¬ 
ties  are  assigned  to  some  hierarchical  domain.  The  entity  relation¬ 
ship  diagram,  if  complex,  can  be  redrawn  to  reflect  this  hierarchy. 

2.3. 2-4  EVB's  Object-Oriented  Requirements  Specification.  A  final 
method  of  object-oriented  requirements  analysis  is  suggested  by  EVB  Software  Engi¬ 
neering.  Inc.  The  requirements  analysis  process  is  documented  in  an  object-oriented 
requirements  specification  (OORS)  which  is  divided  into  an  object-general  section 
and  an  application-specific  section  [EVB,  1989:123], 

Object-General  Section.  The  object-general  section  of  the  OOKS 
contains  an  object  and  class  specification  (OCS)  for  potentially  reusable  objects  and 
classes  required  for  the  problem.  The  OCS  consists  of  the  following  elements: 


•  A  textual  description  of  the  object  or  class 


•  Graphical  representations  of  the  static  and  dynamic  characteristics 
of  the  object  or  class.  The  static  relationships  of  the  object  or  class 
to  other  objects  or  classes  is  captured  in  a  semantic  net  or  entity 
relationship  diagram.  The  dynamic  behavior  of  the  object  or  class  is 
represented  in  a  state  transition  diagram,  or,  for  complex  behaviors, 
in  a  petri  net  graph. 

•  A  list  of  operations  suffered  by  the  object,  or  operations  the  object 
or  class  requires  of  other  objects. 

•  Documentation  of  the  state  information  of  the  object  or  class,  in¬ 
cluding  restrictions  on  the  state  of  the  object. 

•  A  description  of  any  constants  or  exceptions  applicable  for  a  class. 

[EYB,  1989:123] 

Application  Specific  Section.  The  application  specific  section  of 
the  OORS  documents  the  elements  of  the  system  specific  to  the  problem  at  hand. 

1  his  section  contains  four  divisions.  The  first  contains  the  OCSs  for  the  application 
specific  system  components.  The  second  section  consists  of  OCSs  for  any  components 
specified  by  a  design  decision  made  by  the  user  (a  metarequirement).  The  third 
segment  lists  any  qualifications  on  components  based  on  how  or  where  they  are  used 
in  this  system.  The  final  division  of  the  applications  specific  section  is  a  “precise  and 
concise"  description  of  how  the  objects  and  classes  interact  in  the  system  to  solve 
the  problem.  This  description  ties  together  the  elements  of  the  software  system  by 
describing  items  such  as  the  user  interface,  timing  constraints,  system  limitations, 
etc.  [EYB.  1989:241-255] 

Together,  the  object  general  and  application  specific  sections  form  the  object- 
oriented  requirements  specification.  This  OORS  is  the  basis  for  developing  an  object  - 
oriented  design. 

i  Stun  mart/ 

the  widespread  use  of  different  approaches  to  software  development  suggests 
that  there  is  no  single  “right"  way  to  apply  software  engineering  principles.  None 
of  the  proponents  of  the  various  approaches  claim  that  their  method  is  universally 
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applicable;  however,  few  concrete  guidelines  exist  for  determining  which  approach  to 
apply  to  a  particular  problem. 

Regardless  of  the  approach  used  for  software  development,  it  seems  customary 
to  apply  that  strategy  in  both  the  analysis  and  design  phases.  If  a  data  stru'  ture 
oriented  approach  is  used  to  uncover  detail  in  the  analysis  phase,  the  same  tactics 
arc  normally  applied  during  the  design  phase  as  a  basis  for  defining  the  architectural 
structure  of  the  software.  Likewise,  if  software  is  decomposed  based  on  the  fund  iorial 
elements  of  the  system,  activities  in  both  the  analysis  and  design  phases  are  aimed 
towards  specifying  and  constructing  these  functional  elements.  In  either  case,  the 
model  produced  during  the  analysis  phase  maps  naturally  into  the  design  phase. 

The  use  of  object-oriented  techniques  in  the  design  phase  requires  some  pre¬ 
liminary  effort  to  identify  the  objects  required  for  the  solution.  The  application  of 
traditional  analysis  methods  results  in  a  functional  or  data  structure  oriented  model 
of  the  problem  space.  These  models  do  not  map  as  naturally  into  an  object-oriented 
design,  requiring  some  sort  of  translation  into  an  object-oriented  model  of  the  re¬ 
quirements  prior  to  design.  This  translation  may  be  difficult  anil  obscure. 

The  literature  points  to  a  trend  in  applying  object-oriented  techniques  from 
the  inception  of  the  project.  Though  immature,  these  techniques  show  promise1  in 
developing  models  of  software  requirements  that  have  a  more  natural  mapping  into 
an  object  oriented  design. 


III.  An  Object  Oriented  Analysis  Method 


1  he  last  chapter  discussed  the  state  of  the  practice  in  applying  object-oriented 
design.  My  experience  in  teaching  Ada  and  00D  agrees  with  those,  such  as 
[[.addon.  1989],  who  reject  the  informal  strategy  as  the  ba.-is  for  constructing  an 
object-oriented  design.  Students  of  OOD  find  it  difficult  to  come  up  with  an  infor¬ 
mal  strategy  which  is  both  complete  and  descript ive  of  the  problem.  They  seem  to 
be  obsessed  with  the  syntax  of  the  English  paragraph  instead  of  the  meaning  it  is 
supposed  to  portray.  Even  experienced  designers  find  it  difficult  to  come  up  with  an 
informal  strategy  without  working  backwards  from  a  more  intuitive  attempt  at  the 
design. 

The  practice  of  using  traditional  analysis  tools  (e.  g.  DEDs)  to  specify  the 
problem  [Booch,  1986.  Seidewitz  and  Stark,  1986]  is  a  step  in  the  right  direction. 
However,  as  discussed  in  the  previous  chapter,  this  approach  also  has  problems. 
Often,  there  is  not  a  clean,  one-to-one  mapping  between  the  bubbles  on  a  data  ilow 
diagram  and  the  objects  or  operations  in  the  system.  Thus,  the  transformation 
from  these  tools  to  an  object-oriented  design  is  confusing  and  difficult.  Also,  a 
supposed  benefit  of  an  object-oriented  representation  is  that  it  more  closely  matches 
the  structure  of  the  real  world  problem.  It  therefore  seems  to  make  little  sense'  to 
first  model  the  problem  using  function-oriented  tools  and  then  translate  the  mode! 
into  an  object-oriented  representation. 

1  he  objective  of  this  chapter  is  to  present  a  method  of  modeling  software 
requirement s  with  an  object-oriented  approach  from  the  outset.  The  chapter  first 
outlines  the  requirements  for  the  object-oriented  analvsis  l()()A)  method.  Next,  it 
describes  the  general  approach  of  the  method,  and  presents  a  detailed  discussion  ol 
th**  method  steps,  finallv.  it  discusses  the  mapping  of  this  model  into  an  object  - 
<  it  ient  ed  design  . 


■  1.1  Coals  oj  an  Objert-One  nti  d  Analysis  Method 

l'he  following  guidelines  should  be  considered  in  the  formation  of  an  object- 
oriented  analysis  method. 

■1.1. 1  t  scr  Orientation.  The  first  objective  of  an  object-oriented  analysis 
method  is  that  it  be  “user  friendly".  In  other  words,  the  models  developed  under 
the  method  should  be  developed  with  the  user,  or  domain  expert,  in  mind.  Too 
often,  analysis  tools  (with  their  cryptic  syntax)  are  aimed  at  the  design  end  of  the 
life  cycle,  leading  the  analyst  of!  down  a  dangerous  path.  As  Roland  Mitfermeir  put 
it: 

Both  user  and  analyst  are  very  soon  involved  in  too  much  technical  detail 
to  recognize  they  are  travelling  very  well  on  a  good  road,  but  the  road  may 
lead  in  the  wrong  direction.  Users  cannot  discover  this  mistake,  because 
the  symbols  that  are  shown  on  the  analyst’s  road  map  do  not  sufficiently 
relate  to  them,  and  the  analyst  cannot  see  it  either,  because  he  lacks 
knowledge  about  the  detailed  environment.  [Mittermeir,  et  al..  1987:154] 

The  tools  of  the  method  should  be  primarily  graphical,  with  supporting  textual 
information.  The  tools  should  also  require  minimal  instruction,  so  that  domain 
experts  can  quickly  learn  to  develop  or  critique  the  software  models.  The  notation 
of  the  tools  should  be  consistent  whenever  possible. 

■  1.1.  J  Ease  of  Use.  Likewise,  the  analysis  method  should  be  fairly  easy  to 
apply  by  an  analyst.  The  complexities  of  the  requirements  of  a  large  software'  system 
will  tax  the  analyst  enough  without  the  added  difficult ies  of  applying  a  labyrinthine 
'-ei  i>l  steps  and  tools.  Barnes  makes  the  interesting  observation  that  the1  amount 
o!  u so  enjoyed  by  a  particular  method  is  inversely  proportional  to  its  complexity 
Ibirues.  1 


■  i 1.1..3  Information  Captured.  Section  2.2.2  identifies  some  general  elements 
of  the  problem  that  are  captured  in  a  requirements  analysis  method.  These  elements 
included  the  interface  characteristics,  information  domain,  functional  elements,  and 
design  constraints.  These  problem  aspects  should  be  captured  in  the  OOA  method. 
In  addition,  an  object-oriented  analysis  method  is  specifically  concerned  with  iden¬ 
tifying  the  objects  in  the  problem,  defining  the  attributes  of  these  objects,  and 
recognizing  the  active  relationships,  or  messages  passed  among  these  objects. 

.3.1-4  Other  Requirements.  In  addition  to  the  above  goals,  the  object-oriented 
analysis  method  should: 


•  model  the  system  in  a  top-down  hierarchical  manner.  The  details  of 
the  problem  should  be  presented  in  layers  of  abstraction,  beginning 
with  the  most  general  concepts. 

•  support  the  definition  of  embedded  systems  requirements.  After  all. 
this  is  the  stated  application  domain  of  Ada. 

•  support  requirements  analysis  of  large  software  systems.  The  tools 
and  guidelines  should  consider  the  complexities  of  large  systems. 
Tools  (such  as  the  "informal  strategy”)  which  are  useful  only  for 
describing  small  problems  have  limited  use  in  modelling  large  soft¬ 
ware  systems. 

•  include  minimal  redundancy.  Redundant  information  is  useful  in 
checking  the  consistency  between  multiple  views  of  the  problem. 
However,  redundancy  also  makes  it,  difficult  to  update  a  model 
when  that  information  changes.  The  OOA  method  should  empha¬ 
size  modifiability  over  redundancy. 

•  map  into  OOD.  The  output  of  the  analysis  method  should  map 
cleanlv  into  the  design  phase,  where  a  Booch- flavored  Ada  object- 
oriented  design  is  carried  out. 


1  he  general  goals  stated  above  guided  the  select  ion  of  tools  and  steps  whh  a 
mak'1  u))  the  object-oriented  analysis  method  of  this  thesis. 


3.2  General  Approach  to  Object-Oriented  Analysis 

The  ideas  which  make  up  the  object-oriented  analysis  method  were  synthe¬ 
sized  from  many  sources.  The  method  was  greatly  influenced  by  the  works  of 
[Booch.  1986],  [Vourdon,  1989],  [EYB.  1989],  and  others.  The  influence  of  EYB's 
object,  class  specification  (OCS)  is  particularly  evident  in  the  method's  description 
of  each  class  of  objects.  However,  despite  some  similarities  in  the  form  of  class  doc¬ 
umentation,  this  OOA  method  is  clearly  different  from  EVB's  in  the  method  steps 
and  tools  used  to  identify  the  objects  and  operations  of  the  problem. 

3.2.1  Role  in  the  Life  Cycle.  The  generic  view  of  the  software  life  cycle  con¬ 
sists  of  three  phases:  definition,  development,  and  maintenance  [Pressman.  1987:27], 
The  OOA  method  addresses  the  software  requirements  analysis  activity  in  the  def¬ 
inition  phase.  The  method  assumes  that  a  systems  analysis  has  already  been  done 
to  define  the  hardware-software  boundary. 

If  there  are  areas  of  uncertainty  in  the  software  requirements,  then  a  series  of 
prototypes  may  be  justified  to  better  understand  these  areas.  Tools  in  the  OOA 
method  may  help  to  document  desired  modifications  to  the  prototypes.  At  some 
point  it  will  be  possible  to  identify  the  requirements  for  a  major  release.  The  OOA 
method  can  then  be  used  to  document  this  baseline  set  of  requirements  in  a  speci¬ 
fication.  I  his  object-oriented  requirements  specification  will  be  useful  later  during 
development  and  (especially)  maintenance  of  the  software. 

1  lie  OOA  method  does  not  attempt  to  identify  all  potential  objects  that  will 
bo  present  in  the  final  design.  The  method  will  only  identify  those  objects  which 
are  evident  from  the  definition  of  the  problem  and  software  interface.  The  designer 
should  expect  to  identify  additional  objects  and  operations  during  the  development 
phase  that  are  required  for  the  complete  solution.  The  distinction  between  analysis 
and  design  is  a  fine  line  an  attribute  of  an  object  is  an  object  in  its  own  right  at 
t  lie  next  lower  level  of  abstract  ion.  The  analyst  should  document  objects  and  classes 
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to  t he  level  of  abstraction  where  the  domain  expert  is  confident  that  the  essence  of 
the  problem  is  captured. 

3.2.2  Method  Tools.  The  object-oriented  analysis  method  was  conceived  by 
first  identifying  the  tools  and  models  required  to  satisfy  the  goals  listed  in  section  3.1 . 
Once  the  end  products  of  the  OOA  model  were  selected,  the  steps  in  constructing 
this  model  were  defined. 

The  OOA  method  attempts  to  bridge  the  gap  between  the  problem  domain 
expert  and  the  designer.  The  nature  of  the  communication  with  these  parties  is 
different.  The  domain  expert’s  view  of  the  world  often  lacks  the  structure  desired 
by  the  designer.  Therefore,  the  analysis  method  must  transform  an  unstructured 
view  of  the  problem  into  one  which  is  structured  enough  to  minimize  uncertainty 
and  ambiguity.  The  method  steps  are  guidelines  for  this  transformation  from  the 
domain  expert's  view  to  the  designer's  view.  These  steps  are  not  automatic — they 
require  the  intuitive  judgement  of  the  analyst  and  review  of  the  domain  expert  to 
fill  in  any  gaps  in  the  representation  of  the  software  requirements. 

3.2.2. 1  Communication  with  the  Domain  Expert.  In  the  OOA  method, 
communication  with  the  domain  expert  is  handled  primarily  through  concept  maps, 
story  boards,  and  a  list  of  external  events  and  desired  responses.  As  described 
in  section  2. 2. .3. 5,  the  concept  map  is  an  unstructured  entity  relationship  diagram. 

1  he  unstructured  nature  of  the  concept  map  enables  the  domain  expert  to  draw 
and  understand  it  with  minimal  training.  This  set,  of  concept  maps  communicates 
a  general  understanding  of  the  problem  elements  to  the  analyst  and  designer.  The 
maps  are  also  used  to  identify  the  objects  describing  the  problem  and  their  attributes. 

I  he  even! /response  list  identifies  external  stimuli  to  which  the  software  must 
respond.  I  he  story  boards  provide  a  means  of  depicting  scenarios  from  which  the 
events  and  responses  are  identified.  I  he  events  will  later  be  viewed  as  messages  that 
need  t  o  be  passed  bet  ween  objects,  in  t  he  form  of  an  ob  ject  calling  upon  an  opera t  i<  m 
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provided  by  another  class  of  objects.  The  response  of  an  object  to  a  message  may  also 
imply  additional  messages  that  the  object  must  send  to  other  objects  in  the  system. 
Together,  the  concept  maps  and  event/response  list  paint  an  insightful  picture  of  the 
software  requirements. 

3. 2. 2. 2  Communication  with  the  Designer.  The  information  from  the 
domain  expert's  concept  maps,  story  boards,  and  event /response  list  is  conveyed  to 
the  designer  through  a  set  of  entries  in  an  “object  encyclopedia'1.  This  encyclopedia 
is  similar  in  concept  to  a  data  dictionary,  but  its  entries  contain  more  comprehensive 
information  than  a  traditional  data  dictionary.  The  major  components  of  such  an 
entry  are: 


•  A  textual  description  of  the  object  or  class. 

•  An  interface  diagram  showing  the  messages  an  object  or  class  re¬ 
ceives  and  passes  to  other  objects. 

•  A  structure  diagram  illustrating  the  sub-objects  or  attributes  of  a 
class  of  objects. 

•  A  state  transition  diagram  displaying  the  states  of  an  object  and  the 
transitions  among  them. 

l  liese  items  are  described  in  more  detail  in  section  3. 3. 2. 6. 

3.3  Steps  in  the  Object-Oriented  Analysis  Method 

1  he  Object-Oriented  Analysis  (OOA)  method  consists  of  the  following  steps: 

1.  Capture  the  domain  expert's  view  of  the  software.  This  is  accomplished 
through  the  following  actions: 


a)  Define  the  overall  purpose  of  the  software. 

bj  Draw  a  set  of  general  concept  maps  which  describe  the  overall  prob- 


c)  Outline  any  user  interface  and  operational  scenarios  with  story 
boards. 

d)  Produce  an  event/response  list  for  the  software. 

e)  Identify  known  restrictions  on  the  size,  reliability,  or  execution  time 
constraints  of  the  software. 

f)  Identify  any  domain  expert  imposed  design  decisions  ( “metarequire¬ 
ments'1 )  for  the  software. 

2.  Model  the  software  requirements  in  a  top-down,  hierarchical  manner.  In 
this  phase,  the  following  guidelines  apply: 

a)  Draw  an  external  interface  diagram  for  the  software  component. 

b)  Identify  any  high  level  actor  objects  which  perform  some  overall 
algorithm. 

c)  Construct  a  preliminary  object  list. 

d)  Identify  the  senders  and  receivers  of  the  messages/events. 

e)  Document  the  object  classes. 

These  steps  are  covered  in  more  detail  in  the  following  paragraphs. 

3.3. 1  Step  One:  Capture  the  Domain  Expert's  View.  The  first  step  of  the 
object-oriented  analysis  method  aims  at  capturing  the  domain  expert's  view  of  the 
problem.  Step  One  may  be  performed  either  by  an  analyst  working  with  one  or 
more  domain  experts,  or  by  the  domain  experts  themselves.  The  emphasis  in  this 
step  is  in  conveying  understanding  of  the  problem  from  the  domain  expert (s)  to  the 
analyst.  At  this  point,  little  structure  is  imposed  on  the  information  raptured. 

3.3.1. 1  Step  la:  Define  the  overall  purpose  of  the  software.  The  state¬ 
ment  of  purpose  simply  gives  the  reader  a  starting  point  for  understanding  the  re¬ 
quirements  of  the  proposed  software  system.  The  length  of  this  description  may 
vary  with  the  complexity  of  the  system,  but  can  Ire  as  short  as  a  single  sentence,  lo 
emphasize  oniv  the  essential  elements  of  the  problem,  the  upper  limit  should  be  one 


3.3. 1.2  Step  lb:  Draw  general  concept  maps  of  the  problem.  These  con¬ 
cept  maps  are  to  provide  a  general  understanding  of  the  elements  of  the  overall  prob¬ 
lem.  At  this  point,  no  structure  is  imposed  on  the  format  of  the  concept  maps.  The 
domain  expert  is  free  to  lay  out  the  problem  as  he  sees  fit.  The  maps  will  later  serve 
as  the  basis  for  identifying  the  objects  of  the  problem  space  and  their  characteristics. 

There  are  a  number  of  sources  of  input  into  concept  maps.  The  analyst  may 
draw  upon  a  textual  statement  of  preliminary  requirements,  observe  the  design  or 
operation  of  a  previous  system,  conduct  surveys,  or  interview  domain  experts.  When 
developing  concept  maps  from  interviews,  it  is  important  for  the  analyst  to  do  some 
"homework"  before  the  interview  so  he  has  some  idea  of  the  important  aspects  of 
the  problem.  Initial  concept  maps  may  be  redrawn  later  to  clean  them  up. 

When  drawing  a  set  of  concept  maps,  the  analyst  should  keep  in  mind  the 
central  concept  of  each  particular  map.  The  maps  should  identify  both  static  (struc¬ 
tural)  and  dynamic  relationships  between  the  entities.  The  maps  should  concentrate 
on  the  problem  aspects  that  are  important  to  the  software  solution— it  should  not 
emphasize  physical  details  (e.g.  color,  physical  location)  that  are  not  important 
to  the  solution  of  the  problem.  Likewise,  a  single  map  should  not  be  packed  with 
too  much  detail.  If  the  concept  map  does  not  fit  cleanly  on  a  single  page,  attempt 
to  move  the  “peripheral”  concepts  and/or  relationships  to  more  detailed  maps  and 
concentrate  on  the  central  concept  of  the  individual  map. 

The  perception  of  the  problem  by  domain  experts  may  change  over  time  due 
to  recent  problems  or  situations.  Also,  different  domain  experts  may  have  different 
views  of  the  problem.  Therefore,  it  is  desirable  to  obtain  concept  maps  from  several 
experts  in  the  application  domain,  and  over  a  period  of  time.  These  maps  will  have 
common  nodes,  indicating  the  most  common  and  consistent  elements  of  the  problem. 

1  he  concept  maps  should  then  be  combined  into  a  single  set  of  maps  portraying  a 
consolidated  understanding  of  the  problem.  This  set  of  concept  maps  may  then  i><- 
reviewed  by  the  domain  experts  in  an  attempt  to  breed  a  consensus  view  of  the 
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problem. 


3.3. 1.3  Step  tc:  Construct  story  boards.  Story  boards  serve  as  an  early 
paper  prototype  of  the  proposed  soft.vare.  Story  boards  are  useful  in  specifying  the 
physical  layout  of  a  user  interface.  Screen  displays  and  menus  can  be  drawn  in  story 
boards,  giving  the  domain  expert  and  analyst  a  feel  for  the  system  as  it  plays  out  a 
number  of  situations  through  different  story  boards.  However,  story  boards  are  not 
limited  to  portraying  only  the  physical  layout  of  display  screens.  Story  boards  can 
be  annotated  with  logical,  as  well  as  physical,  entities  depicting  the  state  of  some 
object  as  it  responds  to  external  stimuli. 

These  models  for  the  interaction  of  the  software  with  the  environment  are  useful 
to  prototype  the  “look  and  feel"  of  the  software  at  an  early  point  in  the  life  cycle. 
A  series  of  story  boards  can  assist  in  capturing  a  sequence  of  interactions  between 
the  soft  warn  and  the  environment,  much  like  a  comic  strip  tells  a  story  through  its 
sequence  of  frames. 

This  sequence  of  actions  portrayed  through  the  story  boards  is  useful  in  acting 
out  scenarios  the  software  may  face.  The  scenarios  will  be  useful  in  later  steps  to 
identify  external  events  and  responses,  and  to  construct  state  transition  diagrams 
for  object  classes. 

3.3.1./,  Step  Id:  Produce  an  event /response  list  for  the  software  system. 
The  event /response  list  provides  an  action-oriented  view  of  the  problem  1o  comple¬ 
ment  the  more  structural  view  portrayed  in  the  concept  maps.  This  list  will  include 
all  events  external  to  the  software  to  which  it  must  respond.  The  event /response-  list 
includes  a  short  description,  of  the  response  to  each  event,  as  well  as  any  information 
concerning  tin-  frequency  and  volume  of  the  event  and  any  maximum  response  time. 
If  the  event  is  periodic  in  nature,  the  analyst,  should  note  this  fact. 

When  developing  the  event /response  list,  it  may  be  helpful  for  the  analyst 
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and  domain  expert  to  walk  through  different  scenarios  from  the  perspective  of  the 
software  system.  These  scenarios,  acted  out  through  the  aid  of  the  story  boards, 
may  aid  in  the  identification  of  events  to  which  the  software  must  respond.  The 
events  and  responses  evident  from  these  scenarios  form  the  heart  of  the  list.  Some 
of  the  arcs  on  the  domain  expert's  concept  map  which  are  labeled  with  action  verbs 
are  also  potential  candidates  for  these  events.  The  events  in  the  list  may  be  initiated 
either  periodically,  or  due  to  some  stimuli  from  an  entity  external  to  the  software 
component. 

The  responses  to  each  event  should  be  written  in  enough  detail  with  respect 
to  the  problem  elements.  For  example,  if  an  event  in  a  cruise  control  system  is 
the  pressing  of  the  accelerate  button,  the  associated  response  should  be  specific  as 
to  what  needs  to  be  done  by  the  system.  Therefore,  “increment  the  desired  speed" 
is  probably  better  than  “go  faster”.  An  event  may  require  multiple  or  conditional 
responses.  If  the  response  is  complex,  it  may  warrant  more  than  a  simple  sentence. 

The  analyst  should  cross-check  the  set  of  concept  maps  and  the  event /response 
list.  Each  object  stated  or  implied  from  the  nouns  in  the  event/response  list  should 
be  included  in  the  set  of  concept  maps  previously  developed.  Although  this  may 
require  redrawing  the  concept  maps,  it  ensures  that  the  concept  maps  adequately 
address  all  phases  of  the  problem.  The  event/response  list  and  concept  maps  may 
be  developed  concurrently. 

I  he  event /response  list  will  be  used  in  phase  two  of  the  method  to  aid  in 
identifying  the  messages  passed  between  objects. 

3.3. 1.5  Step  le:  Identify  any  restrictions  on  the  software.  Any  known 
physical  or  regulatory  restrictions  on  the  software  should  obviously  be  stated  as 
early  as  possible.  Such  restrictions  may  include  the  size,  reliability,  execution  time, 
or  security  of  the  software.  Documenting  this  information  at  this  time  could  avert  a 
cost  ly  design  error. 
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3.3. 1.6  Step  If:  Identify  any  “rnetarequirements,' .  Metarequirements 
are  design  decisions  imposed  on  the  system  by  the  user  (or  even  higher  authority). 
For  example,  use  of  a  certain  internal  data  base  format  may  be  dictated  to  ensure 
consistency  with  existing  or  future  software. 

3.3.2  Step  Two:  Add  Structure  to  the  Requirements.  The  second  phase  of 
the  object-oriented  analysis  method  entails  modeling  the  software  requirements  in  a 
top  down,  hierarchical  manner.  Each  class  of  objects,  and  their  inter-relationships, 
are  identified  and  documented  in  this  phase  of  the  method. 

3.3.2. 1  Step  2a:  Draw  an  external  interface  diagram  of  the  software 
component.  This  diagram  puts  the  software  system  in  context  with  the  outside  en¬ 
vironment.  The  events  in  the  event  list  (with  the  possible  exception  of  periodic 
events)  will  come  from  the  external  entities  shown  in  this  diagram.  The  external 
entities  often  show  up  on  the  set  of  concept  maps  developed  in  the  first  phase  of  the 
method. 


3. 3.2.2  Step  2b:  Identify  any  high  level  actor  objects  which  perform 
some  overall  algorithm.  When  implemented  in  Ada.  the  “middle  part”  of  the  exter¬ 
nal  interface  diagram  is  often  an  all-encompassing  actor  object  which  sends  messages 
to  other  objects  to  dictate  the  flow  of  control  of  the  software.  The  algorithm  run  by 
this  object  is  the  “glue’’  which  ties  all  of  the  objects  together  by  defining  a  sequence 
to  the  sending  of  messages. 

the  need  for  such  a  high  level  actor  object  is  hinted  at  in  figure  3.1.  L  ho 
real-world  objec  s  and  operations  of  the  problem  are  encapsulated  into  software 
[('presentations  of  the  entities.  Apart  from  this,  there  may  be  an  algorithm  which 
manipulates  the  objects  in  the  problem.  In  Booch-flavored  object-oriented  design, 
this  algorithm  takes  the  form  of  a  high-level  actor  object  sending  messages  to  t  he 
objects.  (The  nature  of  this  high  level  algorithm  may  be  similar  to  the  “informal 
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Figure  3.1.  Relationship  of  Objects  and  Algorithms  [Booch.  1983:39] 

strategy"  of  Booch’s  initial  00D  method.)  This  overall  object  is  typically  the  "main 
program"  in  an  Ada  implementation  of  OOD.  If  the  algorithm  implemented  by  this 
overall  object  is  complex,  this  object  may  be  broken  down  into  subobjects,  imple 
mented  by  Ada  tasks,  each  implementing  different  logical  areas  of  the  problem.  An 
example  is  the  Environment  Monitoring  design  problem  in  [Booch.  1987b], 

At  the  highest  level  of  abstraction,  it  may  be  difficult  to  distinguish  between  a 
high-level  actor  object  and  a  functional  process.  The  definition  of  an  object  presented 
in  the  last  chapter  requires  that  an  object  maintain  some  state  information.  However, 
this  state  may  be  simply  the  composite  st.  ‘S  of  each  of  its  sub-objects. 
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At  this  step  in  the  method,  the  analyst  should  identify  any  high-level  algorithm 
controlling  the  objects.  In  complex  problems,  this  highest-level  object  should  now 
be  decomposed  into  multiple  actor  objects,  each  controlling  some  logical  area  of  the 
problem.  At  this  point,  the  analyst  would  then  draw  a  structure  diagram  of  the 
top-level  object  to  illustrate  this  decomposition.  The  domain  expert’s  concept  maps 
and  the  event /response  list  may  provide  some  insight  into  this  decomposition. 

3. 3. 2. 3  Step  2c:  Construct  a  preliminary  object  list.  The  next  step  of 
the  method  is  to  construct  a  working  list  of  objects  that  will  potentially  appear  in 
the  solution.  The  objects  will  normally  come  from  the  concept  names  on  the  domain 
expert's  concept  maps.  The  nouns  in  the  description  of  anv  high-level  algorithm 
may  also  imply  additional  objects.  In  addition  to  these  guidelines,  the  concepts  of 
abstraction  and  information  hiding  may  help  divide  the  problem  up  into  objects.  In 
the  spirit  of  [Parnas,  1972],  each  object  should  hide  the  implementation  of  some  ab- 

^uL.ov  Lium  the  p.obiern.  Include  entities  from  the  external  interface  diagram 
in  this  list. 

Once  a  list  of  objects  is  identified,  group  the  objects  with  similar  characteris¬ 
tics  under  the  name  of  a  class  that  encompasses  those  objects.  If  there  is  a  "large" 
number  of  object  classes,  attempt,  to  group  logically  related  object  classes  into  sub¬ 
systems.  A  subsystem  denotes  a  logical  collection  of  cooperating  structures  and  tools 
[Hooch,  1987a:615],  In  other  words,  one  can  think  of  a  subsystem  as  a  set  of  logically 
related  objects  that  forms  some  entity  at  a  higher-level  of  abstraction.  The  grouping 
of  objects  should  form  a  manageable  hierarchy  of  subsystems  and  objects. 

3. 3. 3. 4  Step  2d:  Identify  message  senders  and  receivers,  harh  of  the 
events  in  the  event /response  list  can  hr  viewed  as  a  message  between  t  wo  objects. 

I  he  response  corresponding  to  each  event  briefly  describes  the  algorithm  to  be  im¬ 
plemented  by  the  receiver  of  the  message.  This  step  requires  the  analyst  to  identifv 
the  render  and  receiver  for  each  of  these  messages. 
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If  the  event  has  more  than  one  response,  it  may  he  that  these  responses  should 
be  performed  by  different  software  objects.  In  this  case,  identify  which  objects 
pertorm  each  of  the  responses.  The  main  receiver  of  the  message  will  then  have  to 
forward  the  message  tc  other  objects  to  signal  them  of  the  event. 

If  none  of  the  objects  previously  identified  are  appropriate  as  a  sender  or  re¬ 
ceiver  of  the  message,  this  is  an  indication  that  either  an  external  entity  is  missing, 
or  that  the  object(s)  identified  thus  far  are  not  adequate.  A  new  object  may  have  to 
be  added  to  the  list.  However,  periodic  events  may  have  no  explicit  sender,  unless 
the  source  is  some  timer  object. 

3. 3.3.5  Step  2e:  Document  the  object  classes.  Each  object  class  is  doc¬ 
umented  with  an  entry  in  the  “object  encyclopedia”.  Descriptions  of  external  ent  ities 
are  included  if  their  interface  is  modeled  in  software. 

The  analyst  begins  by  drawing  an  interface  diagram  for  the  top-level  actor 
object.  This  diagram  shows  the  access  requirements  between  the  high-level  object 
and  the  objects  at  a  certain  level  of  abstraction.  At  the  top  level,  most  of  the 
messages  from  the  system-level  event /response  list  will  appear  as  arcs  between  I  ho 
all-encompassing  object  with  other  objects.  However,  it  may  happen  that  some  of 
the  messages  from  the  system-level  list  may  be  more  appropriate  at  a  lower  level  of 
abst  raetion.  At  some  point  in  the  analysis  review,  the  analyst  should  ensure  that  all 
events  in  the  event/response  list  are  shown  as  messages  to  an  object. 

1* or  each  class  of  objects  shown  on  the  interface  diagram,  the  analyst  enters  a 
new  reference  in  the  ‘‘object  encyclopedia".  If  new  objects  from  the  problem  space 
are  uncovered,  they  are  included  in  the  list  of  objects  developed  earlier.  (Be  careful 
not  to  add  objects  to  the  list  that  are  only  part  of  the  solution  and  are  not  required 
to  describe  the  problem  These  objects  will  be  identified  in  the  design  phase.) 

When  modeling  external  ent  it  ies  as  objects,  t  he  classificat  ion  of  t  hose  external 
objects  as  actors  or  servers  depends  on  the  nature  of  the  external  device  (i.e.  polled 
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vs.  interrupt  driven).  Some  of  these  external  entities  (such  as  a  keyboard)  may  he 
accessed  through  the  operating  system  instead  of  implemented  as  a  software  object. 
In  this  case,  documentation  of  these  purely  hardware  entities  may  not  add  anything 
to  idle  specification. 

In  some  circumstances  it  may  be  helpful  to  more  explicitly  document  the  in¬ 
teraction  between  multiple  objects.  In  this  case,  the  analyst  may  want  to  include  a 
separate  Petri  Net  Graph  depicting  this  complex  interaction  among  objects. 

This  process  is  repeated  at  lower  levels  of  abstraction  until  all  objects  from 
the  object  list  are  documented,  and  the  software  is  modeled  to  such  a  level  of  detail 
where  the  problem  is  well  understood.  As  stated  in  section  3.2.1,  the  object-oriented 
analysis  method  concentrates  on  defining  the  problem  with  respect  to  its  interface 
with  the  outside  world,  as  defined  by  the  domain  expert.  To  attempt  to  document 
the  problem  below  this  level  seems  to  involve  specifying  more  of  the  "how"  than  the 
"what"  of  the  problem.  The  analyst  should  try  to  refrain  from  inadvertently  crossing 
this  tine  line  between  analysis  and  design. 

■S.J.3.6  Contents  of  an  “ Object  Encyclopedia"  entry.  Each  class  of  ob¬ 
jects  in  the  object  encyclopedia  is  documented  with  a  textual  description  of  the 
object,  a  structure  diagram  (showing  its  attributes/sub-object. s).  an  interface  dia¬ 
gram  (showing  the  communication  of  this  object  to  other  objects  in  the  system), 
a  state  transition  diagram  (if  appropriate),  a  description  of  any  limitations  on  an 
object's  state,  a  characterization  of  messages  received  (operations  provided),  a  de¬ 
scription  of  messages  sent  (operations  required)  to  other  objects,  a  list  of  exceptional 
terror)  conditions  the  object  flags,  a  list  of  constants  exported,  a  list  of  objects  in 
the  Hass  being  documented,  and  any  reuse  considerations  for  the  class. 

I  he  textual  description  of  a  class  of  objects  simply  states  the  purpose  ol  the 
object  d...  ■ .  It  also  may  include  any  miscellaneous  information  about  the  class  not 
included  anvwhere  else. 
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The  structure  diagram  is  a  "pseudo"  concept  map.  It  contains  concepts  and 
relationships  as  in  a  standard  concept  map.  but  the  relationships  are  limited  to  the 
structural  relationships  of  the  class  being  described.  The  structure  diagram  exposes 
the  internal  view  of  a  class  of  objects,  documenting  its  attributes  or  sub-objects.  It 
can  be  drawn  using  as  a  guide  the  concepts  linked  by  structural  verbs  (e.  g.  is  a.  has 
a.  etc.  )  on  the  domain  expert's  concept  map. 

The  interface  diagram  is  also  a  "pseudo'’  concept  map.  It  displays  the  external 
view  of  the  class — messages  sent  or  received  by  the  class.  When  drawing  an  interface 
diagram  for  a  class  of  objects,  it  is  helpful  to  list  the  events  and  responses  for  the 
individual  class.  This  list  aids  the  analyst  in  identifying  the  messages  sent  and 
received.  The  events  should  match  with  the  messages  received  by  the  object  class, 
while  the  response  descriptions  (along  with  the  action-verb  links  on  the  domain 
expert's  concept  map)  will  hint  at  the  messages  sent  to  other  objects.  The  messages 
sent  and  received  by  the  object  are  documented  in  the  corresponding  text  as  well. 
This  text  further  describes  the  significance  of  each  of  the  messages.  In  the  list  of 
messages  sent,  the  class  name  of  the  receiving  class  is  included,  unless  the  class  is 
reusable  and  the  receiving  class  varies  between  objects  in  the  class. 

I  lie  state  transition  diagram  (STD)  for  the  class  of  objects  may  also  aid  the 
analyst  in  identifying  messages  that,  an  object,  receives.  The  STD  may  indicate 
that  a  certain  message  must  be  received  to  transition  into  a  certain  state.  The 
analyst  may  also  study  the  structure  diagram  for  the  class  to  ascertain  whether  a 
selector,  constructor,  or  iterator  operation  need  be  provided  for  each  attribute.  1  lie 
blent  ifirat  ion  of  operat  ions  required  and  provided  should  be  influenced  by  t  he  concept 
of  object  coupling.  It  is  desirable  lor  an  object  to  exhibit  black  box  coupling,  where 
the  method  for  each  message  received  requires  knowledge  of  only  the  class  being 
documented,  rather  than  while  box  coupling  where  the  method  requires  knowledge 
■  >1  e.t  her  objects  in  its  implement  at  ion  (h  VB.  1  Mil],  Finally,  if  a  message  received 
by  the  class  ol  objects  involves  a  complex  algorithm  in  its  response,  an  outline  ol 
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this  algorithm  may  he  included  in  the  message  description. 

The  analyst  draws  the  state  transition  diagram  based  on  any  state  information 
implied  in  the  domain  expert's  concept  map.  story  hoards,  or  event /response  list. 
The  messages  received  by  an  object  may  indicate  a  change  of  the  object's  state  is 
required.  Limitations  may  exist  on  the  state  of  an  object.  These  limitations  may 
include: 

•  A  limit  on  the  number  of  items  in  a  homogeneous  composite  item. 

•  A  limit  on  the  range  of  values  in  a  scaler  class. 

•  A  limit  on  the  length  of  time  an  object  may  be  in  a  particular  state. 

These?  limitations  are  documented  in  the  textual  information  for  the  class. 

The  series  of  structure  and  interface  diagrams  defines  a  hierarchical  mode!  ol 
the  objects  in  the  problem  space.  The  object  encyclopedia  entries  may  be  grouped 
either  alphabetically  or  hierarchically,  from  the  highest  lev?']  of  abstraction  to  the 
lowest.  The  hierarchical  grouping  of  entries  seems  best  managed  with  a  software 
tool  so  that  the  analyst  can  easily  get  from  one  level  of  abstraction  to  another.  The 
requirements  for  such  a  tool  are  described  in  the  next  chapter. 

Finally,  the  object-oriented  analysis  method  assumes  that  the  domain  expert 
will  be  involved  in  reviewing  the  products  produced  by  the  analysis.  1 1  is  input  a:id 
review  is  essential  in  phase  one;  in  fact  the  domain  expert(s)  may  perform  this  phase 
of  the  analysis  independent  of  a  separate  analyst.  The  domain  expert's  review  is 
also  crucial  to  the  success  of  the  model  of  the  requirements  developed  in  the  second 
phase  of  the  OOA  method.  Although  the  nature  of  this  model  is  more  structured 
than  the  first  phase,  the  domain  expert  should  be  able  to  follow  the  model  as  an 
extension  to  the  concept  maps  and  event  list  he  provided  earlier.  1  lie  !ina!  model  i  >i 
lie-  requirements  provides  the  bridge  between  the  domain  expert  and  the  designer, 
-o  but  h  mould  mi  deist  and  and  agree  on  t  he  model  1  a- fore  more  formal  design  hem  ns. 


3.3.3  Sample  Analysis  Problem.  The  following  example  shows  the  OOA 
method  applied  to  the  requirements  analysis  of  a  typical  cruise  control  system  for 
an  automobile.  Enough  of  the  analysis  is  presented  to  provide  an  indication  of  the 
intended  use  of  the  method  tools. 

3.3.3. 1  Step  One:  Capture  the  Domain  Expert’s  View.  Phase  One  of 
the  method  entails  the  following  steps: 

Step  la:  Define  the  Overall  Purpose  of  the  Software. 

I  he  cruise  control  system  adjusts  the  automobile’s  accelerator  to  automatically 
maintain  a  constant  vehicle  speed. 

Step  lb:  Draw  a  Set  of  General  Concept  Maps  Which  Describe  the  Over¬ 
all  Problem. 

The  set  of  concept  maps  is  shown  in  figure  3.2  and  figure  3.3. 


I 
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(•'iiinro  Concept  Map:  Cruise  Cont  ml  Svstem 


Figure  3.3.  Concept  Map:  Cruise  Control  Buttons 
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The  ca  e  control  powers  up  in  the  “off”  state.  Before  it  is  turned  on  and  set  tc  a  specific  speed,  the  cruise  emu  i . .1 
will  remain  idle.  Only  the  “on”  button  will  have  any  effect  in  this  state. 

Figure  3.4.  Cruise  Control  Story  Board:  Initial  Setting 

Step  lc:  Outline  the  User  Interface  and  Operational  Scenarios  with  Story 
Boards. 

There  are  no  screen  displays  in  the  cruise  control  system.  The  speedometer 
does  give  an  indication  that  the  cruise  control  is  operating,  hut  the  cruise  control 
system  does  not  directly  manipulate  it.  However,  story  boards  are  useful  for  revealing 
the  reaction  of  the  cruise  control  system  to  various  inputs  from  the  environment.  A 
few  such  scenarios  are  portrayed  in  the  story  boards  in  figures  3.4.  3.3.  3.G.  3.7.  and 
3.T  Other  story  boards  could  be  added  for  a  more  complete  description  of  the  cruise 
rout rol  svstem. 


3-31 


When  the  “on"  button  is  pressed,  the  cruise  control  change*,  state,  from  ‘off”  to  “on".  The  cruise  control  svstei 
will  now  respond  to  the  “set”  button. 

Figure  3.5.  Cruise  Control  Story  Board:  On  Button  Pressed 


When  the  "set”  hut  ton  is  pressed  while  the  cruise  control  is  in  the  “on"  state,  t  he  cruise  rnnt  ml  enter*  t  he  “engaged 
■•late,  I  he  desired  speed  is  set  to  the  current  speed,  and  the  cruise  control  begins  to  control  the  throttle  <  ontr- 
wh*-n  '  hanges  in  speed  are  necessary. 


Hgurf3.fi.  Cruise-  Control  Story  Board:  Set  Button  Pressed 
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tf  the  brake  is  pressed  while  the  cruise  control  is  engaged,  the  system  is  disengaged  and  transitions  to  the  "on" 
state.  The  throttle  control  is  no  longer  active.  The  desired  speed,  however,  remains  set  to  its  value  in  anticipation 
of  a  later  command  to  resume  the  cruise  control  system. 

Figure  3.7.  Cruise  Control  Story  Board:  Brake  Pressed 


[f  the  <  urrent  speed  drops  below  the  desired  speed  while  the  cruise  control  is  engaged,  the  cmisc  control  system 
■•ends  a  signal  to  the  throttle  control  to  accelerate  the  vehicle.  This  accelerate  signal  will  continue  until  the  current 
"p*'ed  is  equal  to  or  greater  than  the  desired  speed. 

l  iguro  3.S.  Cruisr  Cont rol  Story  Board:  Sport!  Drops 
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Step  Id:  Produce  an  Event/Response  List  for  the  Software. 


Event  1:  The  on  button  is  pressed. 

Resp.l:  The  cruise  control  system  is  activated. 

Maximum  response  time:  0.5  seconds. 

E2:  Set  speed  button  is  pressed. 

R2a:  Cruise  control  system  is  engaged. 

R2b:  Set  the  desired  speed  equal  to  the  current  speed. 

Maximum  response  time:  0.25  seconds. 

E3:  Time  to  update  the  throttle  position  (periodic). 

R3:  If  engaged,  then  set  the  throttle  based  on  the  current  speed  vs.  the 
desired  speed. 

Projected  event  rate:  10  /  second. 

E  l:  Brake  is  pressed. 

Rl:  Cruise  control  system  is  disengaged. 

Maximum  response  time:  0.1  seconds. 

E5:  Resume  button  is  pressed. 

115:  Cruise  control  is  engaged. 

Maximum  response  time:  0.25  seconds. 

EG:  Accelerate  button  is  pushed. 

Rf>:  Increment  desired  speed. 

Maximum  response  time:  0.25  seconds. 
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E7:  The  off  button  is  pressed. 

R7a:  Throttle  control  is  disengaged. 

R7b:  Cruise  control  is  deactivated. 

Maximum  response  time:  O.i  seconds. 

Step  le:  Identify  Known  Restrictions  on  the  Software. 

•  The  cruise  control  system  object  code  must  fit  within  16K  of  mem¬ 
ory. 

•  The  cruise  control  system  must  disengage  if  the  break  is  pressed  at 
least  99.99999%  of  the  time. 

Step  If:  Identify  any  “metarequirements”. 

The  maximum  speed  allowed  for  setting  the  cruise  control  system  is  100  miles 
per  hour. 

3.3. 3.2  Step  Two:  Model  the  Software  Requirements  in  a  Top-Down . 
Hierarchical  Manner.  Phase  Two  of  the  method  consists  of  the  following  steps: 

Step  2a:  Draw  an  External  Interface  Diagram  for  the  Software  Compo¬ 
nent. 

I  he  external  interface  diagram  is  shown  in  figure  3.9. 

Step  2b:  Identify  any  High  Level  Actor  Objects  which  Perform  Some 
Overall  Algorithm. 

.None.  The  algorithm  of  the  cruise  control  system  object  is  not  complex  enough 
to  decompose.  1  he  object  is  documented  in  the  object  encyclopedia. 


Figure  3.!).  Cruise  Control  System:  Kxternal  Interface  Diairram 
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Step  2c:  Construct  a  Preliminary  Object  List. 


Cruise  Control 

Throttle  control 

Speed 

Current  Speed 
Desired  Speed 

Button 

Set  Button 
On  Button 
Off  Button 
Resume  Button 
Accelerate  Button 


Timer 

Step  2d:  Identify  the  Senders  and  Receivers  of  the  Messages/Events. 


Event  1:  I’he  on  button  is  pressed. 

Sender:  On  Button 
Receiver:  Cruise  Control 

H2:  Set  speed  button  is  pressed. 

Sender:  Set  Button 
Rereiver:  Cruise  Control 

R'2a:  Cruise  control  system  is  engaged.  (Performed  by  Cruise  Control) 

R'2l>:  Set  the  desired  speed  equal  to  the  current  speed.  (Performed  by 
Cruise  Control) 
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E3:  Time  to  update  the  throttle  position  (periodic). 

Sender:  Timer 
Receiver:  Cruise  Control 

Ft:  Brake  is  pressed. 

Sender:  Brake 
Receiver:  Cruise  Control 

F.5:  Resume  button  is  pressed. 

Sender:  Resume  Button 
Receiver:  Cruise  Control 

E6:  Accelerate  button  is  pushed. 

Sender:  Accelerate  Button 
Receiver:  Cruise  Control 

E7:  The  off  button  is  pressed. 

Sender:  Off  Button 
Receiver:  Cruise  Control 

R7a:  Throttle  control  is  disengaged.  (Performed  by  Cruise  Control) 

R7b:  Cruise  control  is  deactivated.  (Performed  by  Cruise  Control) 

Stop  2e:  Document  the  Object  Classes. 

I  lie  following  pages  document  representative  classes  of  objects  present  in 
cruise  control  problem. 
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Cruise  Control  Object 

Textual  Description: 

The  cruise  control  is  the  brain"  of  the  cruise  con  ol  system.  It  keeps  track 
of  the  state  of  the  cruise  control  system  and  periodically  updates  the  position  of  the 
throttle  to  maintain  a  constant  vehicle  speed. 

Structure  Diagram,  Interface  Diagram,  and  State  Transition  Diagram: 

See  figure  3.10,  figure  3.11.  and  figure  3.12. 

Description  of  messages  received: 

Break  pressed  Signal  that  the  break  pedal  has  been 

pressed 

Set  button  pushed  Signal  that  the  set  butt  on  has  been  pressed 

OIF  button  pushed  Signal  that  the  Oil  out  Ion  has  been  pressed 

On  button  pushed  Signal  that  the  On  button  has  been  pressed 

Resume  button  pushed  Signal  that  the  Resume  button  has  been 

pressed 

Accelerate  button  pushed  Signal  that  the  Accelerate  button  has  been 

pressed 

Update  Throttle  Signal  that  it  is  time  to  update  the  throttle 

position 
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1'i^nn- 3. 10.  f’ruisi*  ( 'ont.rol:  Structure  Diagram 
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Brake  Pressed 
Set  Button  Pressed 
OfT  Button  Pressed 
On  Button  Pressed 
Resume  Bui  ton  Pressed 
Accelerate  Button  Pressed 
Update  Throttle 


Cruise 

Control 


Disengage 

Accelerate 
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Description  of  messages  sent: 


Speed  Senior. Determine  Speed 

Speed. Greater  Than 

Speed.  Assign 

Desired  Speed. Increment 

Throttle.  Accelerate 

Tli rot  tie.  Decelerate 

I  hrottle. Disengage 


Get  the  current  speed  from  the  speed  sen¬ 
sor 

Determine  if  one  speed  is  greater  than  an¬ 
other 

Assign  one  value  of  class  speed  to  another 
Increment  the  value  of  the  desired  vehicle 
speed 

Set  the  throttle  to  make  the  vehicle  accel¬ 
erate 

Set  the  throttle  to  make  the  vehicle  decel¬ 
erate 

Release  control  of  the  vehicle  throttle 


Description  of  an>  state  limitauions: 

The  cruise  control  object  must  initialize  in  the  ’‘Off"'  state. 
List  of  exported  exceptions: 

None. 

List  of  exported  constants: 

None. 

Reuse  considerations: 

1  his  object  is  application  specific. 
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Button  Class 


Textual  Description: 

The  button  class  models  a  physical  button.  When  the  button  is  pushed,  a 
signal  is  sent  to  some  receiver.  In  this  application,  the  receiver  for  all  button  objects 
is  the  cruise  control  object. 

Structure  Diagram,  Interface  Diagram,  and  State  Transition  Diagram: 

See  figures  3.13  and  3.14. 

Description  of  messages  received: 

None. 

Description  of  messages  sent: 

Signal  Signal  the  receiver  that  the  button  has  been  pressed. 

Description  of  any  state  limitations: 

None. 

List  of  exported  exceptions: 

None. 

List  of  exported  constants: 

None. 

List  of  objects  in  the  class: 


•  On  Button 

•  Off  Button 

•  Set  Button 

•  Accelerate  Button 

•  Resume  Button 


Figure  3.14.  Button:  Interface  Diagram 

Note:  In  each  case  the  receiver  of  the  signal  is  the  cruise  control  object 
Reuse  considerations: 

This  object  is  potentially  reusable. 


Speed  Class 


Textual  Description: 

This  class  describes  objects  which  represent  the  speed  of  the  vehicle.  This  class 
is  based  on  the  integer  class. 

Structure  Diagram  and  Interface  Diagram: 

See  figures  3.15  and  3.16. 


Figure  3.15.  Speed:  Structure  Diagram 

State  Transition  Diagram: 

See  figure  3. 1 7. 

Description  of  messages  received: 

( I  ri  m  t  rr  1  han 
Increment 


\"i!inment 


Test  if  one  speed  is  greater  than  another 
Increment  the  value  of  the  speed. 

Assign  one  value  of  speed  to  another. 


Fignrr-  -5. 1  7.  Speed:  State  Transition  Diagram 
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Description  of  messages  sent: 


None. 

Description  of  any  state  limitations: 

An  object  of  this  class  may  have  a  value  in  the  range  0..100. 

List  of  exported  exceptions: 

Constraint  Error  An  attempt  was  made  to  increment  a  speed 
object  which  was  at  its  maximum  value 

List  of  exported  constants: 

Maximum  speed. 

List  of  objects  in  the  class: 

•  Current  Speed 

•  Desired  Speed 

Reuse  considerations: 

This  object  has  limited  reuse  potential. 


Entries  would  also  be  placed  in  the  object  encyclopedia  for  the  remainder  * >1 
the  objects  in  the  object  list. 


•  >’.  f  Mapping  to  an  Object-Oriented  Design 

The  model  pioduced  hv  the  OOA  method  maps  directly  into  a  Booeh-fiavored 
object-oriented  design.  Any  high-level  algorithm  is  documented,  as  are  all  classes  of 
objects  in  the  problem  space.  With  the  possible  exception  of  certain  external  ent  it  u  s. 
each  ciass  of  objects  documented  in  the  object  encyclopedia  will  likely  be  par)  of 
the  design.  The  class’s  entry  in  the  object  encyclopedia  contains  the  information 
required  to  design  the  object. 

Some  details  of  the  object  classes  were  intentionally  ignored  in  the  analysis 
phase.  For  example,  while  OOA  method  identified  the  messages  passed  between 
objects,  it  made  no  attempt  to  define  the  arguments  of  these  calls.  The  argumenis 
of  messages  are  often  at  a  level  of  abstraction  lower  than  the  class  being  d  >cumented. 
I  herefore.  cataloging  these  arguments  was  deferred  until  the  design  phasr 

Likewise,  the  nature  of  the  implementation  of  each  class  of  objects  was  not 
addressed  during  analysis.  Whether  objects  are  concurrent  with  other  objects  is 
one  such  implementation  detail  deferred  until  design.  All  objects  are  potentially 
concurrent — only  efficiency  considerations  prevent  the  designer  from  actually  imple¬ 
menting  the  objects  in  this  manner.  It  is  the  designer's  responsibility  to  determine 
t  ho  implementation  of  each  object. 

As  the  designer  defines  the  software  solution,  he  will  undoubtedly  discover 
more  objects  and  operations  to  be  implemented.  For  example,  if  the  designer  make- 
an  object  concurrent,  he  may  have  to  add  operations  to  initialize  and  terminate  the 
object.  I  hr'  details  of  the  solution  will  also  present  more  object  classes  than  w<  re 
documented  during  analysis  In  practice,  information  must  bo  collected  about  these 
new  object  classes  as  well.  Therefore,  the  designer  may  continue  where  the  analyst 
left  rdf.  and  use  similar  tools  to  those  listed  above  in  documenting  objects  identified 
'lut  ing  t  fie  design  phase. 


T  til 


The  tools  and  procedures  defined  in  this  chapter  make  up  the  object  oriented 
analysis  (00  A)  method.  The  domain  expert  and  analyst  may  use  paper  and  pencil 
to  document  this  information.  However,  a  computer-aided  tool  will  greatly  assist 
the  analyst  in  creating  and  reviewing  t he  documentation.  Such  a  tool  would  also 
give  more  of  a  hierarchical  nature  to  the  entries  in  the  object  encyclopedia.  The 
requirements  for  such  a  tool  are  outlined  in  chapter  IV.  The  OOA  method  is  more 
fully  evaluated  in  chapter  V,  when  the  method  is  applied  to  a  more  comprehensive 
requirements  analysis  problem. 


IV.  Requirements  for  an  Object-Oriented  Analysis  Tool 


The  previous  chapter  suggested  the  creation  of  a  software  tool  to  manage  tne 
products  and  process  of  the  object-oriented  analysis  method.  This  chapter  describes 
a  user  interface  and  set  of  guidelines  for  the  design  of  such  a  tool.  The  purpose  ol 
this  description  is  to  show  the  potential  benefits  the  OOA  method  can  receive  irom 
automated  support.  Although  some  of  the  tools  from  the  OOA  method  are  used  in 
tins  description,  this  chapter  is  not  an  example  of  the  OOA  method— a  complete 
application  on  an  example  problem  is  presented  in  chapter  V.  A  more  complete 
specification  and  design  of  the  OOA  tool  is  recommended  as  a  future  project  Ise- 
section  6.3). 


/.  /  Franu  work  for  OOA  Tool  Dcscnpt ion 

The  Object-Oriented  Analysis  Tool  contains  many  characteristics  ol  a  Dmsion 
Support  Sp.'-h  m  i  DSS).  The  tool  is  aimed  at  providing  support  to  the  analyst  in  his 
attempt  to  model  the  software  requirements.  The  proposed  OOA  tool,  however, 
does  not  se<’ m  to  fit  the  definition  of  a  "true"  DSS.  A  typical  DSS  contains  some 
type  of  model  that  draws  upon  a  data  base  of  information  in  order  to  provide  a 
quantitative  assessment  -’rich  will  assist  a  decision  maker.  At  the  beginning  ol  the 
-oft  ware  requirements  analysis  activity,  there  is  li'tle  information  that  would  be  m 
an  existing  database  (other  than  a  library  of  reusable  components)  and  no  lornial 
model  to  draw  upon  the  information  that  does  exist.  The  OOA  method  is  more 
>>l  a  rnnlin  process  than  an  analytic  one.  guided  by  heurist’cs  instead  ol  mode!-. 
Ne\ ert  helevs.  ,i  DSS  framework  can  lx*  used  t.o  identify  t  he  nature  of  the  OOA  '  o<  d  - 

U-er  mterfaee. 

Sprague  and  Carlson  have  proposed  a  process-independent  approach  tm  idee 
t  ifvirm  the  capabilities  of  a  DSS.  Ini'-  approach  emphasizes  the  conAderat  ion  oi 
I  ’e; n  e-ent  a t  tot i  u  Opera t  i (Mis.  Memorv  aids,  and  font  ro|  mechanisms  i  H OMf  t.  h'<  p- 
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nsr illations  communicate  information  about  the  problem  to  the  user,  often  using  a 
report  or  graphical  format.  The  DSS  should  provide  a  set  of  operations  to  manipu¬ 
late  the  information  in  the  representations.  Memory  aids  assist  or  guide  the  user  in 
applying  the  operations  on  the  representations.  The  control  mechan isms  enable  the 
user  to  direct  the  session  with  the  tool,  and  get  from  one  set  of  representations  to  an¬ 
other  [Sprague  and  Carlson,  1982:96].  The  ROMC  principles  guided  the  description 
of  the  00 A  tool  user  interface  presented  here. 

i  he  chapter  uses  two  previously  describe  tools,  the  concept  map  and  story 
board,  to  present  the  00A  tool  description.  The  concept  maps  identify  the  elements 
of  t  he  object-oriented  requirements  specification  produced  by  the  OOA  method.  I  he 
maps  also  identify  the  information  ( memory  aids)  upon  which  a  specific  element  of 
the  specification  depends.  The  storyboards  describe  a  proposed  user  interface  for 
the  OCA  tool.  They  were  created  to  describe  the  automated  support  for  develop¬ 
ing  each  of  the  elements  illustrated  in  the  concept  maps.  The  development  of  each 
storyboard  considered  the  representations,  operations,  memory  aids,  and  control 
mechanisms  appropriate  for  that  step  in  the  OOA  method. 

■f.J  Relationships  Among  Models  in  the  Object-Oriented  Analysis  Method 

Many  of  the  steps  in  the  Object-Oriented  Analysis  (OOA)  method  are  based 
'in  the  work  of  previous  steps.  With  this  in  mind,  one  ran  draw  a  set  of  concept 
maps  reflecting  these  relationships  among  the  models  developed  in  the  method. 

Figure  1.2  shows  a  concept  map  describing  the  overall  OOA  method.  As  de¬ 
fined  in  the  previous  chapter,  the  OOA  method  has  two  major  steps:  capturing  the 
software  requirements  from  the  domain  expert,  and  structuring  those  requirements 
into  a  lorm  suitable  for  design.  I  he  later  process  of  object-oriented  design  is  based 
primarily  on  this  structured  representation,  though  the  initial  concept  maps  ami 
storyboards  may  also  influence  the  designer. 

1  he  elements  of  the  initial,  unstructured  model  of  the  requirements  are  dlu- 


Figure  4.2.  Concept  Map:  Capturing  the  Requirements 

t rated  in  figures  4.2,  4.3,  and  4.4.  These  maps  point  out  some  of  the  relationships 
among  the  different  models.  For  example,  the  event /response  list  is  based  on  the 
domain  expert's  concept  map  and  storyboards,  while  the  concept  map  is  verified 
against  the  event/response  list.  An  OOA  tool  can  assist  the  analyst  in  applying  the 
method  steps  by  informing  the  analyst  of  these  relationships  among  models,  and 
providing  a  means  of  displaying  previous  information  upon  which  a  specific  model  is 
based. 

I  he  models  developed  in  the  second  step  of  the  OOA  method  display  a  similat 
reliance  upon  previous  models.  For  example,  the  external  interface  diagram  is  based 
on  both  the  domain  expert's  concept  maps  and  the  event /response  list.  Figures  I.T 
and  l.fi  describe  the  primary  relationships  between  these  models  in  further  detail. 
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|  Figure  4.5.  Concept  Map:  Structuring  t  > .  .rrpiiremrnts 
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-{■■!  General  Requirements  for  an  Object-Oriented  Analysis  Tool 

First  and  foremost,  the  OOA  tool  should  be  “user  friendly”.  This  is  especially 
important  in  light  of  the  fact  that  the  domain  expert  may  be  the  one  using  the 
tool  to  enter  initial  concept  maps,  storyboards,  and  event/response  lists.  Therefore, 
the  OOA  tool  should  run  in  a  graphical  windowing  environment,  with  user  input 
allowed  through  menus  and  a  mouse.  Use  of  an  existing  windowing  environment  also 
provides  the  user  the  ability  to  customize  the  size  and  shape  of  the  tools  windows. 
This  flexibility  enhances  the  tool's  ability  to  support  a  range  of  user  preferences. 

Because  the  models  developed  during  the  course  of  analysis  depend  on  prev  ious 
representations,  the  OOA  tool  should  enable  the  user  to  view  am1  edit  multiple  views 
simultaneously.  Therefore,  the  windowing  environment  should  enable  the  user  to 
open  multiple  windows  with  different  models  of  the  requirements. 

To  assist  the  novice  user,  the  system  should  provide  a  reference  to  context 
sensitive  help  windows.  This  help  should  be  of  two  kinds.  H  should:  1)  provide 
assistance  on  the  use  of  the  OOA  tool  itself,  and  2)  suggest  guidelines  for  applying 
the  steps  of  the  OOA  method.  Also,  the  OOA  tool  should  be  consistent  in  the 
presentation  of  screens  and  menus.  Menu  selections  that  are  present  in  all  windows 
(e.  g.  Help)  should  be  positioned  in  the  same  relative  position  in  each  menu.  Ill  is 
positioning  will  minimize  the  "learning  curve"’  of  a  new  user. 

Occasionally,  the  analyst  may  have  a  random  thought  about  a  topic  not  direct  lv 
related  to  the  model  he  is  currently  working  on.  Therefore,  the  OOA  tool  should 
have  a  notepad  capability  to  provide  an  easy  way  to  rapture  these  thoughts.  I  lie 
notepad  may  also  be  used  to  record  any  difficulties  encountered  while  using  the  OOA 

t  ool . 

In  cases  where  there  is  overlap  of  information  among  different  models  in  the 
OOA  method,  the  OOA  tool  should  ensure  that  the  different  representations  are 
consistent.  For  example,  the  OOA  tool  could  ensure  that  each  class  of  object  in 
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the  list  of  potential  objects  is  documented  with  an  entry  in  the  object  encyclopedia. 
Other  potential  cross  checks  the  tool  could  perform  include: 


•  verifying  that  each  event  in  the  event/response  list  has  beep  cataloged  with  a 
message  sender  and  receiver. 

•  ensuring  that  each  message  in  the  list  of  messages  shows  up  on  the  interface 
diagram  for  some  object  class. 

•  confirming  each  message  sent  or  received  by  a  class  of  objects  shows  up  on 
both  the  interface  diagram  and  the  textual  description  for  that  class. 

•  verifying  that  the  list  of  messages  received  by  a  particular  class  includes  each 
of  the  messages  identified  in  other  classes  as  being  sent,  to  that  object. 

The  general  requirements  cataloged  above  (along  with  the  concept  maps  pre¬ 
sented  earlier  in  this  chapter)  are  sufficient  to  carve  out  a  set  of  storyboards  which 
illustrate  the  "look  and  feel”  of  an  00A  tool. 

4-4  Storyboards  of  the.  Object-Oriented  Analysis  Tool 

The  relationships  between  model  elements  shown  in  (he  concept  maps  and 
discussed  in  section  4.2  furnish  insight  into  the  requirements  for  a  software  tool  to 
assist  in  applying  the  OOA  method.  Each  step  in  the  OOA  method  can  he  supported 
through  a  menu  choice  of  the  OOA  tool.  The  tool  will  assist  the  analyst  in  each  step 
by  providing  access  to  the  information  that  each  step  is  based  on. 

The  initial  screen  of  the  OOA  tool  is  shown  in  figure  4.7.  This  window  has 
a  number  of  characteristics  that  are  common  to  other  windows  presented  by  the 
OOA  tool.  Windows  of  this  nature  can  be  constructed  with  a  number  of  different 
windowing  systems;  the  format,  shown  is  characteristic  of  Microsoft  Windows  for 
the  IBM  PC  class  computer.  Clicking  the  mouse  on  the  small  box  in  the  upper 
left  corner  of  the  window  presents  a  menu  of  window  commands,  such  as  resizing. 
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moving,  or  closing  the  window.  By  closing  the  main  window,  the  user  conclude- 
a  session  with  the  OOA  tool.  The  arrowed  boxes  in  the  upper  right  hand  corner 
allow  the  user  to  expand  the  window  to  cover  the  entire  screen,  or  to  shrink  the 
window  into  an  icon.  Other  menu  choices  are  presented  in  rows  across  the  top  of 
the  window.  An  exclamation  point  at  the  end  of  a  menu  choice  denotes  an  action 
which  takes  place  immediately  when  choice  is  selected.  A  menu  choice  lacking  tin- 
trailing  exclamation  point  will  request  more  information  from  the  user  before  tin- 
action  is  taken.  Windows  may  also  have  scroll  bars  to  move  the  window  over  a 
larger  underlying  drawing  or  text. 

The  initial  screen  of  the  OOA  too!  integrates  all  steps  of  the  OOA  method. 
From  this  display,  the  user  has  access  to  the  models  developed  in  both  step  one 
1  Capture  Requirements)  and  step  two  (Structure  Requirements)  of  the  OOA  method. 
From  this  window,  the  user  may  also  load  an  existing  project,  or  clear  the  tool  for 
a  new  project.  Commands  also  allow  saving  the  project,  printing  all  models  and 
documentation,  and  access  to  the  notepad  and  help  functions. 

■{..{•  t  Capturing  Software  Requirements.  Figure  1.8  displays  the  menu  choices 
for  tools  which  support  capturing  the  software  requirements  under  step  one  of  the 
OOA  method.  It  the  user  selects  the  Text!  option,  ihe  window  shown  in  figure  l.!l 
is  created.  I  his  window,  and  similar  windows  described  later,  do  not  take  up  the 
entire  screen.  This  allows  the  user  access  to  the  main  menu,  and  thus  other  models 
developed  during  the  analysis.  Of  course,  the  analyst  may  always  click  (lie  mouse  on 
the  "up"  arrow  in  the  box  in  the  upper  right  corner  to  expand  the  window  to  cover 
the  ent ire  screen. 

From  t  he  Capture Rrqts  menu,  the  user  may  also  develop  and/or  view  a  concept 
map  ( see  figure  1.10).  storyboard  (figure  1.11).  or  even! /response  list  (figure  1.1.21. 
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I'll  is  is  the  main  screen  of  the  00A  tool.  The  window  format  and  commands  of  this  window  are  similar  to  those* 
used  for  other  screen  displays.  Clicking  the  left  mouse  button  on  the  small  box  in  the  tipper  left  comerof  the  window- 
presents  a  menu  of  window  commands,  such  as  dost,  or  resize.  Clicking  on  the  arrow  boxes  in  the  upper  right  hand 
of  the  window  allows  the  user  maximize  the  window  to  cover  the  entire  screen,  and  shrink  the  window  into  an 

icon. 

The  second  and  third  lines  of  the  window  display  menu  choices  that  may  he  selected  with  the  mouse.  Any  choice 
ending  in  an  exclamation  point  initiates  an  immediate  action,  while  those  without  the  exclamation  point  present 
another  menu  of  choices.  All  windows  have  menu  options  Notepad!  and  ffrlp!.  These  options  allow  the  user  t<> 
across  a  notepad  to  record  random  thoughts  while  using  the  tool,  and  context  sensitive  help  and  guidelines  ibo.it 
flic  system  and  OOA  method. 

The  main  menu  contains  the  following  options: 


•  Capture Rfqts:  Present  the  “Capture  Requirements”  menu  (see  figure  4.8)  to  perform  actions  in  step  one 
(lie  OOA  method. 

•  Structure  Hrqts:  Present  the  “Structure  Requirements”  menu  (see  figure  4.  I'M  to  perform  actions  in  step  tw<. 
of  t lie  OOA  method. 

•  Ijiad P roj< ft:  Present  a  list  of  project  names  that  the  user  may  load. 

•  \rn!:  Clears  the  OOA  tool  for  a  new  project. 

•  Sa  rf  All!:  Save  all  aspects  of  the  project  to  disk.  If  no  project  was  initially  loaded,  the  user  will  be  prompted 
for  tin*  project  name. 

•  I* rmt All!'.  Print,  all  project  documentation. 


Figaro  t .7.  OOA  Tool  Storyboard:  Main  lool 
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Du*  “Capture  Requirements”  menu  allows  the  user  to  make  the  following  choices  for  step  one  of  t  lie  OOA  in*  ili-.-l 

•  le.xth  Document  textual  information  about  the  system  (see  figure  -1.0). 

•  Conr.F.pt  Map!:  Draw  a  set  of  concept  maps  (see  figure  1.10). 

•  Storyboard!:  Draw  a  set  of  storyboards  (see  figure  4.11). 

•  Event  List!:  Create  an  event /response  list  (see  figure  4.12). 


I'igure  1.8.  OOA  Tool  Storyboard:  Capture  Rcf|uiromonts  Mrtm 
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□ 

CaptureReqts  StructureReqts  LoadProject  New!  SaveAll ! 

PnntAll!  Notepad!  Help! 

Text:  ProjectName  t 

* 

Save!  DiscardChanges 1  Print!  Notepad!  Help1 

Purpose : 

Constraints  (Size,  reliability,  security,  time): 

Metarequirements : 

1 

i 

»>  n*M  the  I'rt!  >«'!»»rimn  is  chosen  from  the  "Capture  Requirements"  m^nu,  the  textual  inf*  »rmaf  ion  input 
appears.  I  his  window  contains  a  template  of  the  textual  information  that  should  he  raptured  from  the 
•Xpert.  I  h'*  initial  position  of  the  window  allows  the  user  to  access  the  main  menu  to  *et  other  informal  i< 
f  h*  proj»M  | .  I  he  s*  roll  bar  on  the  rij^ht  hand  side  of  i  he  window  allows  the  user  to  scroll  through  the  te> 
•  h*  k  of  the  mouse  button. 

ili'’  foilowmt^  menu  *  hoires  are  specific  to  this  window: 

•  •>  i  >  -  '  Save  the  current  textual  information. 

•  /n«  •'I’-'i f  -i n t/;  Discard  changes  to  the  textual  information  since  the  last  save. 

•  I>r*n,>.  I’rint  the  textual  information. 


liuum  !.!).  ()0.\  lool  Slorvboanl:  Irxtnal  Information 


OOA  Tool 


♦  I 


CaptureReqts  StructureRegts  LoadProject  New!  SaveAlli 
PrintAll !  Notepad!  Help! 


□ 

|  Concept  Maps:  ProjectName 

♦ 

New!  Read  AddConcept !  AddRelationship !  Delete  Move 

Save!  SaveAs  DiscardChanges !  Print!  Notepad!  Help! 

|  ^ 

contains 


contains 


among 


Verified  Against  Event/Response  List 


When  the  Concept  Map!  selection  is  chosen  from  the  “Capture  Requirements"  menu,  the  concept  map  win-l.-w 
appears.  This  window  contains  commands  winch  allow  'he  user  to  draw  concept  maps.  The  initial  position  of  ill. 
window  allows  the  user  to  access  the  main  menu  to  get  other  information  about  the  project.  The  bottom  line  of  tin- 
window  displays  the  other  method  steps  upon  which  the  concept  maps  are  based.  The  scroll  bar  on  the  bottom  and 
tight  hand  sides  of  the  window  allow  the  user  to  scroll  through  the  concept  map  with  a  click  of  the  mouse  button. 

1  lie  following  menu  choices  are  specific  to  this  window: 


•  Xf  w!:  Initializes  the  window  to  draw  a  new  concept  map. 

4  Rtad:  Reads  a  concept  map  from  a  file. 

•  AddConrepf!:  Ados  a  concept  to  the  map.  The  user  is  prompted  for  a  label  for  the  concept .  and  is  illowc-i 
to  position  the  concept  with  the  mouse. 

•  A'i'llifl’itionship!:  Adds  a  relationship  between  tv.  »  concepts.  The  user  is  promoted  for  the  label  i«.  ati.i-  ii 
to  the  relationship,  and  is  allowed  to  position  the  abel  with  the  mouse. 

•  I'rlrtt:  This  selection  is  used  to  delete  a  concept  or  relationship.  After  selecting  this  opt'  >».  tlx*  user  «  Ii*  K- 
the  mouse  on  the  concept  or  relationship  to  delete. 

•  A  to  t:  1  his  selection  is  used  to  move  a  •r.rept.  After  selecting  this  option,  the  user  clicks  on  the  <  on.  <  |t 
to  move,  then  drags  it  to  its  new  location. 

•  S  >t  >  >  Save  the  current  concept  map. 

•  >'?>  •  A  n':  Save  the  concept  map  in  a  different  file.  The  user  is  prompted  for  the  name  of  the  new  file. 

•  fhsranif'hangra!:  Discard  changes  to  the  concept  map  since  the  last  save. 

•  /Sirif.'.  I'rint  t lx*  current  concept  map. 


Figure  t  10.  OOA  Fool  Storyboard:  Concept  Maps 
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CaptureReqts  StructureEeqts  LoadProject  New!  SaveAll! _ 

PrintAll!  Notepad!  Help! 

Story  Boards:  Proj ectName  +  I 


New!  Read  Save!  SaveAs  DiscardChanges !  Print! 
Notepad!  Help! 


When  the  Storyboard!  selection  is  chosen  from  the  “Capture  Requirements"  menu,  the  storyboard  window  appears 
I  his  window  connects  to  a  drawing  package  which  allows  the  user  to  draw  free-format  graphics  for  storyboards.  1  h« 
initial  position  of  the  window  allows  the  user  to  access  the  main  menu  to  get  other  information  about  the  project 
Hie  scroll  bar  on  the  bottom  and  right  hand  sides  of  the  window  allow  the  user  to  scroll  through  the  concept  ma; 
with  a  click  of  the  mouse  button. 

I  he  billowing  menu  choices  are  specific  to  this  window: 


•  .V'  u  !:  Initializes  the  window  to  draw  a  storyboard  frame. 

•  Ihni.  Reads  a  storyboard  frame  from  a  file. 

•  >’'/?■'/:  Save  the  current  storyboard  frame. 

•  Sart-A*?:  Save  the  storyboard  frame  in  a  different  file.  The  user  is  prompter!  for  the  name  of  the  new  lil« 

•  l>i*''nrd(  'h‘iv  gts!\  Discard  changes  to  the  storyboard  frame  since  the  last  save. 

•  /Vmt.'.  Print  the  current  storyboard  fram:. 

•  [)rnutt)ij  Commands:  Drawing  commands  specific  to  an  existing  free-format  drawing  program  will  in 
eluded . 


l  ij’nrf*  1.11.  OOA  Tool  Storyboard:  Storyboard  Window 
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Based  On:  Concept  Maps,  Story  Boards 

When  the  Evint  List!  selection  is  chosen  from  the  “Capture  Requirements”  menu,  the  Event /Response  List  win¬ 
dow  appears.  This  window  contains  templates  for  entering  events  to  which  the  software  must  respond,  and  thru 
corresponding  responses.  The  initial  position  of  the  window  allows  the  user  to  access  the  main  menu  to  get  other 
information  about  the  project.  The  bottom  line  of  the  window  displays  the  other  method  steps  upon  which  the 
*  vent /response  list  is  based.  The  scroll  bar  on  the  right  hand  side  of  the  window  allows  the  user  to  scroll  through 
the  list  with  a  click  of  the  mouse  button. 

I  h.-  hd. owing  menu  choices  are  specific  to  this  window': 

•  5 a v f. /:  Save  the  current  concept  map. 

•  Discard  (’hn  ngr  s!:  Discard  changes  to  the  concept,  map  since  the  last  save. 

-  t*r\nt!\  Print  the  current  concept  map. 


Figure*  M2.  OOA  Iool  Storyboard:  F. vent /Response  Fist 
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4-4-~  Structuring  Software  Requirements.  The  Structure  Reqts  menu  (see  fig¬ 
ure  1.13)  provides  a  number  of  tools  which  can  assist  the  analyst  in  adding  structure 
to  the  requirements  to  make  them  sufficient  for  the  object-oriented  design  phase. 
From  this  menu,  the  user  may  choose  to  draw  or  view  an  external  interface  diagram 
i see  figure  4.14),  decompose  any  high-level  algorithm  (see  figure  4.15),  list  potential 
objects  and  classes  (figure  4.16),  list  message  senders  and  receivers  (figure  4.1”).  or 
edit  or  view  ent  ries  in  the  object  encyclopedia  (see  figure  4.18).  Each  of  these  options 
is  discussed  further  in  the  text  corresponding  to  the  storyboards  in  the  figures. 


[he  “Structure  [Requirements"  menu  allows  the  user  to  make  the  following  choices  for  step  two  of  the  OOA  m»th"*l: 

•  E1D!:  Draw  an  external  interface  diagram  (see  figure  1.11). 

•  High- Level  Decomp!:  Draw  a  structure  diagram  depicting  the  decomposition  of  the  high-level  algorithm  ( '■*♦•»• 
figure  *1.15). 

•  Object  ID!:  Enter  a  list  of  potential  objects  in  the  solution  of  the  system  (see  figure  1.1b) 

•  Mug  Send  &  Red:  Document  the  senders  and  receivers  of  messages  corresponding  to  events  in  the  event  h*»t 
f see  figure  4.17). 

•  Object  Enrtjr.f:  Create  entries  in  the  object  encyclopedia  (see  figure  4. 1 S). 

Figure  1.13.  OOA  Tool  Storyboard:  Structure  Requirements  Menu 
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Based  On:  Concept  Map,  Event/Response  List 

When  the  EID!  selection  is  chosen  from  the  “Structure  Requirements”  menu,  the  External  Interface  Diagram  window 
appears.  This  window  contains  commands  which  allow  the  user  to  draw  the  external  interface  diagram.  The  initial 
position  of  the  window  allows  the  user  to  access  the  main  menu  to  get  other  information  about  the  project.  The 
bottom  line  of  the  window  displays  the  other  method  steps  upon  which  the  external  interface  diagram  is  based.  1  h«' 
scroll  bar  on  the  bottom  and  right  hand  sides  of  the  window  allow  the  user  to  scroll  through  the  diagram  with  a 
click  of  the  mouse  button. 

The  following  menu  choices  are  specific  to  this  window: 

s  Adi  Entity1.'.  Adds  an  entity  to  the  map.  The  user  is  prompted  for  a  label  for  the  entity,  and  is  allowed  to 
position  the  concept  with  the  mouse. 

•  AddLink !:  Adds  a  link  between  two  entities.  The  user  is  prompted  for  the  label  to  attach  to  the  link,  and  is 
allowed  to  position  the  label  with  the  mouse. 

•  Delete :  This  selection  is  used  to  delete  an  entity  or  link.  After  selecting  this  option,  the  user  clicks  the  mouse 
on  the  entity  or  link  to  delete. 

•  Move :  This  selection  is  used  to  move  an  entity.  After  selecting  this  option,  the  user  clicks  on  the  entity  to 
move,  then  drags  it  to  its  new  location. 

•  Save!:  Save  the  current  external  interface  diagram. 

•  DiseardChanges !:  Discard  changes  to  the  external  interface  diagram  since  the  last  save. 

•  Print /:  Print  the  current  external  interface  diagram. 


Figure  4.14.  OOA  Tool  Storyboard:  External  Interface  Diagram 
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When  t lie  High-Level  Decomp!  selection  is  chosen  from  the  aStructure  Requirements”  menu,  the  High-Level  De¬ 
composition  window  appears.  This  window  contains  commands  which  allow  the  user  to  draw  a  structure  diagram 
depicting  the  decomposition  of  any  high-level  algorithm  in  the  system.  The  initial  position  of  the  window  allows  the 
user  to  acrevs  the  main  menu  to  get  other  information  about  the  project.  The  bottom  line  of  the  window  displays 
the  other  method  steps  upon  which  the  decomposition  is  based.  The  scroll  bar  on  the  bottom  and  right  hand  sides 
of  the  window  allow  the  user  to  scroll  through  the  diagram  with  a  click  of  the  mouse  button. 

The  following  menu  choices  are  specific  to  this  window: 

•  AddEnttty!:  Adds  a  new  entity  to  the  map.  The  user  is  prompted  for  a  label  describing  the  entity,  and  is 
allowed  to  position  the  bubble  with  the  mouse. 

•  AddRelationship!:  Adds  a  relationship  between  two  entities.  The  user  is  prompted  for  the  label  to  attach  to 
the  relationship,  and  is  allowed  to  position  the  label  with  the  mouse. 

•  Delete :  This  selection  is  used  to  delete  an  entity  or  relationship.  After  selecting  this  option,  the  user  clicks 
the  mouse  on  the  entity  or  relationship  to  delete. 

•  Afore:  This  selection  is  used  to  move  an  entity.  After  selecting  this  option,  the  user  clicks  on  the  entity  to 
move,  then  drags  it  to  its  new  location. 

•  Save!:  Save  the  current  diagram  depicting  the  algorithm  decomposition. 

•  DiscardCkanges!:  Discard  changes  to  the  diagram  since  the  last  save. 

•  Pnntl:  Print  the  current  diagram. 


Figure  4.15.  OOA  Tool  Storyboard:  High-Level  Algorithm  Decomposition 
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Based  On:  Concept  Maps,  Event/Response  List,  EID 

When  the  ObjectID!  selection  is  chosen  from  the  “Structure  Requirements”  menu,  the  Object  Identification  window 
appears.  This  window  allows  the  user  to  enter  a  list  of  potential  objects.  The  initial  position  of  the  window  allows 
the  user  to  access  the  main  menu  to  get  other  information  about  the  project.  The  bottom  line  of  the  window  displays 
the  other  method  steps  upon  which  the  object  identification  is  based.  The  scroll  bar  on  the  right  hand  side  of  the 
window  allows  the  user  to  scroll  through  the  list  with  a  click  of  the  mouse  button. 

The  following  menu  choices  are  specific  to  this  window: 

•  Save!:  Save  the  current  list  of  potential  objects. 

•  Discard  Changes!:  Discard  changes  to  the  list  since  the  last  save. 

•  Print!:  Print  the  current  list  of  potential  objects. 

Figure  4.16.  OOA  Tool  Storyboard:  Potential  Object  List 
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External  Interface  Diagram,  High-Level  Decomp. 

When  the  Msg  Send  &  Rec  selection  is  chosen  from  the  "Structure  Requirements”  menu,  the  Message  Senders  ;i 
Receivers  window  appears.  This  window  allows  the  user  to  annotate  each  event  in  the  event /response  list  wit! 
name  of  the  sender  and  receiver.  The  initial  position  of  the  window  allows  the  user  to  access  the  main  menu  U» 
■»ther  information  about  the  project.  The  bottom  line  of  the  window  displays  the  other  method  steps  upon  wh 
the  identification  of  messages  senders  and  receivers  is  based.  The  scroll  bar  on  the  right  hand  side  of  the  wind 
allows  the  user  to  scroll  through  the  list  with  a  click  of  the  mouse  button. 

1  he  following  menu  choices  are  specific  to  this  window: 


•  Save!:  Save  the  current  list  of  message  senders  and  receivers. 

•  PisrardChanges!:  Discard  changes  to  the  list  since  the  last  save. 

•  Print!:  Print  the  current  list  of  message  senders  and  receivers. 


Figure  1.17.  00A  Tool  Storyboard:  Message  Srnders/Rereivers 
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Story  Boards,  Object  List 


When  the  Object  Encyc.!  selection  is  chosen  from  the  "Structure  Reoeiro.nents"  menu,  the  Object  Encyclopedia 
window  appears.  This  window  contains  commands  which  aiiow  the  user  to  create  entries  in  the  object  encyclopedia. 
The  window  itself  contains  the  textual  information  describing  aspects  of  the  class  of  objects. 

The  following  menu  choices  are  specific  to  this  window: 

•  .Vend:  Create  a  new  entity  to  the  object  encyclopedia. 

•  ReadEntry.  Reads  an  object  encyclopedia  entry  a  file. 

•  S  tructure  Diagram!:  Allows  user  to  draw  a  structure  diagram  for  the  class  of  objects  (see  figure  -4.  19). 

•  Interf  aceDiagram!:  Allows  user  to  draw  an  interface  diagram  for  the  class  of  objects  (see  figure  4.20). 

•  STD!:  Allows  user  to  draw  a  state  transition  diagram  for  the  class  of  objects  (see  figure  4.22). 

•  Delete:  Ibis  selection  is  used  to  delete  an  entry  in  the  object  encyclopedia.  The  user  is  prompted  f«»r  ill* 
name  of  the  entry  to  delete. 

•  Save!:  Save  the  current  object  encyclopedia  entry. 

•  DiscardChanges!:  Discard  changes  to  the  object  encyclopedia  entry  since  the  last  save. 

•  Print!:  Print  the  current  entry  of  the  object  encyclopedia. 


f  igure  1.18.  00 A  fool  Storyboard:  Object  Encyclopedia 
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Based  On:  Concept  Map,  Object  List 


When  the  StructureDiagram!  selection  is  chosen  from  the  “Object  Encyclopedia"  window,  the  Structure  Diagram 
window  appears.  This  window  contains  commands  which  allow  the  user  to  draw  a  structure  diagram  for  a  class 
of  objects.  The  initial  position  of  the  window  allows  the  user  to  access  the  object  encyclopedia  menu  to  get  other 
information  about  the  class  of  objects.  The  user  may  click  on  any  of  the  components  or  attributes  that  make  up  tin- 
class,  and  a  window  with  the  structure  diagram  for  that  class  will  appear.  The  bottom  line  of  the  window  displays 
the  other  method  steps  upon  which  the  structure  diagram  is  based.  The  scroll  bar  on  the  bottom  and  right  hau  l 
sides  of  th~  window  allow  the  user  to  scroll  through  the  diagram  with  a  click  of  the  mouse  button. 

The  following  menu  choices  are  specific  to  this  window: 


•  AddEntity!:  Adds  a  new  entity  to  the  structure  diagram.  The  user  is  prompted  for  a  label  for  the  entity, 
and  is  allowed  to  position  the  entity  with  the  mouse. 

•  AddRelationship!:  Adds  a  relationship  between  two  entities.  The  user  is  prompted  for  the  label  to  attach  to 
the  relationship,  and  is  allowed  to  position  the  label  with  the  mouse. 

•  Delete:  This  selection  is  used  to  delete  an  entity  or  relationship.  After  selecting  this  option,  the  user  clicks 
the  mouse  on  the  entity  or  relationship  to  delete. 


•  Stove:  This  selection  is  used  to  move  an  entity.  After  selecting  this  option,  the  user  clicks  on  the  emiiy  t<» 
move,  then  drags  it  to  its  new  location. 

•  Sane!:  Save  the  current  structure  diagram. 

•  DiscardChanges!:  Discard  changes  to  the  diagram  since  the  last  save. 

•  Print!:  Print  the  current  diagram. 


Figure  4.19.  00A  Tool  Storyboard:  Structure  Diagram 
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Based  On:  List  of  Message  Senders/Receivers,  Object  List 


When  the  fnterfaceDiagram!  selection  is  chosen  from  the  “Object  Encyclopedia"  window,  the  Interface  Diagram 
window  appears.  This  window  contains  commands  which  allow  the  user  to  draw  an  interface  diagram  for  a  <  la>s 
of  objects.  The  initial  position  of  the  window  allows  the  user  to  access  the  object  encyclopedia  menu  to  get  other 
information  about  the  class  of  objects.  The  user  may  click  on  any  of  the  classes  receiving  messages  from  this  class, 
and  the  interface  diagram  for  the  class  will  appear  in  a  new  window.  If  the  user  highlights  the  name  of  an  incoming 
message,  a  window  will  open  with  a  list  of  classes  that  send  this  message  (see  figure  4.21).  The  bottom  line  of  the 
window  displays  the  other  method  steps  upon  which  the  interface  diagram  is  based.  The  scroll  bar  on  the  bottom 
and  right  hand  sides  of  the  window  allow  the  user  to  scroll  through  the  diagram  with  a  click  of  the  mouse  button. 

1  he  following  menu  choices  are  specific  to  this  window: 


•  AddEntity!:  Adds  a  new  entity  to  the  interface  diagram.  The  user  is  prompted  for  a  label  for  the  entity,  and 
is  allowed  to  position  the  entity  with  the  mouse. 

•  AddRelationskip!:  Adds  a  relationship  between  two  entities.  The  user  is  prompted  for  the  label  to  attach  t>* 
the  relationship,  and  is  allowed  to  position  the  label  with  the  mouse. 

•  Deleft:  This  selection  is  used  to  delete  an  entity  or  relationship.  After  selecting  this  option,  the  user  clicks 
the  mouse  on  the  entity  or  relationship  to  delete. 

•  Move:  This  selection  is  used  to  move  an  entity.  After  selecting  this  option,  the  user  dirks  on  the  entity  t>> 
move,  then  drags  it  to  its  new  location. 

•  Save.!:  Save  the  current  interface  diagram. 

•  DiscardChanges!:  Discard  changes  to  the  diagram  since  the  last  save. 

•  Print!:  Print  the  current  diagram. 


figure  t .20.  OOA  Fool  Storyboard:  fntorfaro  Diagram 


When  an  incoming  message  is  highlighted  with  the  right  mouse  button  on  the  interface  diagram,  a  window  .ipp*  .ir- 
with  a  list  of  classes  that  send  the  message  to  this  class.  The  user  may  likewise  highlight  one  of  these  class  nun.  - 
and  a  new  window  will  appear  with  the  interface  diagram  for  the  class. 

Figure  1.21.  OOA  Tool  Storyboard:  Highlighting  Incoming  Message 
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Based  On:  Concept  Maps,  Story  Boards,  E/R  List 

When  the  STD!  selection  is  rhosen  from  the  ‘Object  Encyclopedia"  window,  the  Stale  Transition  Diagram  wind, 
appears  This  window  contains  commands  which  allow  the  user  to  draw  a  state  transition  diagram  for  a  -  l.i^s 
objects.  The  initial  position  of  the  window  allows  the  user  to  access  the  object  encyclopedia  menu  to  g»  t  -<tl 
information  about  the  class  of  ohjects.  The  bottom  line  of  the  window  displays  the  other  method  steps  upon  win 
the  state  transition  diagram  is  based.  The  scroll  bar  on  the  bottom  and  right  hand  sides  of  the  window  allow  ' 
u "c r  to  scroll  through  the  diagram  with  a  dirk  of  the  mouse  button. 

1  he  following  menu  choices  are  specific  to  this  window: 

•  .1  ddSt’itf !:  Adds  a  new  state  to  the  diagram.  The  user  is  prompted  for  a  label  for  the  state,  and  is  allow 
to  position  the  state  with  the  mouse. 

•  i  id  7  ran.utivn!:  Adds  a  transition  between  two  states.  The  user  is  prompted  for  t  lie  label  to  attach  t.,  i 
transition,  ami  is  allowed  to  position  the  label  with  the  mouse 

•  D'i’t'.  I  his  selection  is  used  to  delete  a  state  or  transition.  After  selecting  this  option,  the  user  «  li-  k~  t 
mouse  on  i lie  stale  or  transition  to  delete. 

•  \/e  i f  I  his  select  ion  is  used  to  reposit  ion  a  st  at  e.  Aft  er  select  ing  t  his  opt  ion.  the  user  dirks  on  the  » t  at  •  ■ 
move,  then  drags  it  to  its  new  location. 

•  Save  t  lie  current  state  transition  diagram. 

•  ha  ng's!:  Discard  changes  to  the  diagram  sin*  e  the  last  save. 

•  Print  th-  current  diagram 


I  igurc  1.22.  OOA  Two  I  Storyboard:  State  Transition  Diagram 
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1  he  window  providing  access  to  the  object  encyclopedia  is  unique  in  that  it 
takes  up  the  entire  screen.  This  allows  more  room  for  the  sub-windows  that  can 
In'  opened  within  the  object  encyclopedia.  Again,  the  user  has  flexibility  in  how  ho 
"ants  these  windows  displayed  on  the  screen  bv  clicking  on  the  appropriate  window 
commands. 

The  object  encyclopedia  window  gives  the  analyst  the  following  capabilities: 

•  Adding  textual  information.  This  is  done  through  the  main  window  of  the 

object  encyclopedia. 

•  Drawing  a  structure  diagram  for  the  class  of  objects  (sec  figure  4.19). 

•  Drawing  an  interface  diagram  for  the  class  of  objects  (see  figure  4.20). 

•  Drawing  a  state  transition  diagram  for  the  class  (see  figure  4.22). 

A  major  benefit  of  the  OOA  tool,  as  identified  at  the  end  of  the  previous 
chapter,  is  to  provide  an  ordering  to  the  entries  in  the  object  encyclopedia.  This 
is  accomplished  through  the  structure  and  interface  diagrams.  If  the  analyst  clicks 
the  mouse  on  a  class  of  objects  in  either  of  these  diagrams,  the  OOA  tool  will  load 
the  object  encyclopedia  entry  for  that  class  of  objects.  If  the  class  of  objects  does 
not  yet  have  an  entry  in  the  object  encyclopedia,  the  user  will  be  asked  if  he  want.' 
to  start  such  an  entry.  This  capability  of  clicking  on  objects  or  classes  from  the 
‘-tincture  or  interface  diagrams  allows  the  user  to  traverse  the  object  encyclopedia 
entries  in  a  hierarchical  manner.  The  analyst  can  thus  load  the  highest  level  object, 
and  traverse  through  the  diagrams  to  view  lower  level  classes, 

/.  >  'nil rlii.  inr 

I  he  concept  maps  and  storyboards  in  this  chapter  describe  a  tool  to  assist  the 
domain  expert  and/or  analyst  in  applying  t  he  object-oriented  ,  nalysis  met  hod.  I  his 
tool  would  also  provide  a  means  of  viewing  the  entries  in  the  object  encvciopediu  in 
.i  hierarchical  manner. 
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V.  Validation  of  the  Object-Oriented  Analysis  Method 


[lie  concepts  proposed  in  this  thesis  as  an  Object-Oriented  Analysis  Method 
can  be  substantiated  by  applying  the  method  to  a  sample  analysis  problem.  This 
chapter  introduces  this  sample  problem  and  discusses  the  application  of  the  method 
to  the  problem. 

I  he  results  of  applying  the  OOA  method  to  the  sample  problem  ran  be  an¬ 
alyzed  from  a  number  of  perspectives.  The  results  will  first  be  compared  with  tin- 
goals  of  the  OOA  method  identified  in  chapter  111.  Also,  the  method  will  be  com¬ 
pared  to  tin'  results  produced  by  two  other  analysis  methods  proposed  as  a  precursor 
to  001). 

■  >.  /  Analysis  Problem  Description 

The  example  problem  used  to  evaluate  the  OOA  method  is  one  which  requires 
f  he  analysis  of  a  typical  elevator  control  system.  The  problem  descript  ion.  taken  from 
j'tourdon.  lb*!.)],  was  first  used  in  a  1986  workshop  sponsored  by  the  Association  of 
Computing  Machinery.  The  following  paragraphs  outline  the  problem. 


1  he  general  requirement  is  to  design  and  implement  a  program  to  sched¬ 
ule  and  control  four  elevators  in  a  building  with  10  floors.  The  elevators 
will  be  used  to  cariy  pe  >ph  from  one  floor  to  another  in  the  conventional 
way. 

hjjieiniry:  The  program  should  schedule  the  elevators  efficiently  and 
reasonably.  For  example,  if  someone  summons  an  elevator  by  pushing 
the  down  button  on  the  fourth  floor,  the  next  elevator  that  readies  the 
fourth  lloor  traveling  down  should  stop  at  the  fourth  floor  to  accept  the 
passenger(s).  On  the  other  hand,  if  an  elevator  has  no  passengers  (no 
outstanding  destination  requests),  it  should  park  at  t he  last  floor  it  visited 
until  it  is  needed  again.  An  elevator  should  not  reverse  its  direction  of 
travel  until  its  passengers  who  want  to  travel  in  its  current  direction 
have  reached  their  destinations.  (As  we  will  see  below,  the  program 


cannot  really  have  information  about  an  elevator's  actual  passengers-, 
it  only  knows  about  destination  button  presses  for  a  given  elevator.  For 
example,  if  some  mischievous  or  sociopathic  passenger  boards  the  elevator 
at  the  first  floor  and  then  presses  the  destination  buttons  for  the  fourth, 
fifth,  and  twentieth  floor,  the  program  will  cause  the  elevator  to  travel 
to  and  stop  at  the  fourth,  fifth,  and  twentieth  floors.  The  computer  and 
its  program  have  no  information  about  actual  passenger  boardings  and 
exits.)  An  elevator  that  is  filled  to  capacity  should  not  respond  to  a  new 
summon  request.  (There  is  an  overweight  sensor  for  each  elevator.  The 
computer  and  its  program  can  interrogate  these  sensors.) 

Destination  button:  The  interior  of  each  elevator  is  furnished  with  a  panel 
containing  an  array  of  40  buttons,  one  button  for  each  floor,  marked 
with  the  floor  numbers  (1  to  40).  These  destination  buttons  can  be 
illuminated  by  signals  sent  from  the  computer  to  the  panel.  When  a 
passenger  presses  a  destination  button  not  already  lit ,  the  circuitry  behind 
the  panel  sends  an  interrupt  to  the  computer  (there  is  a  separate  interrupt 
for  each  elevator).  When  the  computer  receives  one  of  these  (vectored) 
interrupts,  its  program  can  read  the  appropriate  memory  mapped  eight- 
bit  input  registers  (there  is  one  for  each  interrupt,  hence  one  for  each 
elevator)  that  contains  the  floor  number  corresponding  to  the  destination 
button  that  caused  the  interrupt.  Of  course,  the  circuitry  behind  the 
panel  writes  the  floor  number  into  the  appropriate  memory-mapped  input 
register  when  it  causes  the  vectored  interrupt.  (Since  there  are  40  floors 
in  this  application,  only  the  first  six  bits  of  each  input  register  will  be 
used  by  the  implementation;  but  the  hardware  would  support  a  building 
with  up  to  256  floors.) 

Destination  button  lights:  As  mentioned  earlier,  the  destination  buttons 
can  be  illuminated  (by  bulbs  behind  the  panels).  When  the  interrupt 
service  routine  in  the  program  receives  a  destination  button  interrupt,  it 
should  send  a  signal  to  the  appropriate  panel  to  illuminate  the  appropri¬ 
ate  button.  This  signal  is  sent  by  the  program's  loading  the  number  of 
the  button  into  the  appropriate  memory-mapped  output  register  (there 
is  one  such  register  for  each  elevator).  The  illumination  of  a  button  noti¬ 
fies  the  passenger(s)  that  the  system  has  taken  note  of  his  or  her  request 
and  also  prevents  further  interrupts  caused  by  additional  (impatient?) 
pressing  of  the  button.  When  the  controller  stops  an  elevator  at  a  floor, 
it  should  send  a  signal  to  its  destination  button  panel  to  turn  off  the 
destination  button  for  that  floor. 

Floor  sensors:  There  is  a  floor  sensor  switch  for  each  floor  for  each  ele¬ 
vator  shaft.  When  an  elevator  is  within  eight  inches  of  a  floor,  a  wheel 
on  the  elevator  closes  the  switch  for  that  floor  and  sends  an  interrupt  to 
the  computer  (there  is  a  separate  interrupt  for  the  set  of  switches  in  each 


elevator  shaft).  When  the  computer  receives  one  of  these  (vectored)  in¬ 
terrupts,  its  program  can  read  the  appropriate  memory  mapped  eight-bit 
input  register  (there  is  one  for  each  interrupt,  hence  one  for  each  elevator) 
that  contains  the  floor  number  corresponding  to  the  floor  sensor  switch 
that  caused  the  interrupt. 

Arrival  lights:  The  interior  of  each  elevator  is  furnished  with  a  panel 
containing  one  illuminable  indicator  for  each  floor  number,  this  panel 
is  located  just  above  the  doors.  The  purpose  of  this  panel  is  to  tell  the 
passengers  in  the  elevator  the  number  of  the  floor  at  which  the  elevator  is 
arriving  (and  at  which  it  may  be  stopping).  The  program  should  illumi¬ 
nate  the  indicator  for  a  floor  when  it  arrives  at  the  floor  and  extinguish 
the  indicator  for  a  floor  when  it  leaves  a  floor  or  arrives  at  a  different 
floor.  This  signal  is  sent  by  the  program’s  loading  the  number  of  the  floor 
indicator  into  the  appropriate  memory-mapped  output  register  (there  is 
one  register  for  each  elevator). 

Summons  buttons:  Each  floor  of  the  building  is  furnished  with  a  panel 
containing  summon  button(s).  Each  floor  except  the  ground  floor  (floor  1 ) 
and  the  top  floor  (floor  40)  is  furnished  with  a  panel  containing  two  sum¬ 
mon  buttons,  one  marked  UP  and  one  marked  DOWN.  The  ground  floor 
summon  panel  has  only  an  UP  button.  The  top  floor  summon  panel 
has  only  a  DOWN  button.  Thus,  there  are  78  summon  buttons  alto¬ 
gether,  39  Up  buttons  and  39  DOWN  buttons.  Would-be  passengers 
press  these  buttons  in  order  to  summon  an  elevator.  (Of  course,  the 
would-be  passengers  cannot  summon  a  particular  elevator.  The  sched¬ 
uler  decides  which  elevator  should  respond  to  a  summon  request.)  These 
summon  buttons  can  be  illuminated  by  signals  sent  from  the  computer 
to  the  panel.  When  a  passenger  presses  a  summon  button  not  already 
lit ,  the  circuitry  behind  the  panel  sends  a  vectored  interrupt  to  the  com¬ 
puter  (there  is  one  interrupt  for  UP  buttons  and  another  for  DOWN 
buttons).  When  the  computer  receives  one  of  these  two  (vectored)  inter¬ 
rupts,  its  program  can  read  the  appropriate  memory  mapped  eight-bit, 
input  register  that  contains  the  floor  number  corresponding  to  the  sum¬ 
mon  button  that  caused  the  interrupt.  Of  course,  the  circuitry  behind 
the  panel  writes  the  floor  number  into  the  appropriate  memory-mapped 
input  register  when  it  causes  the  vectored  interrupt. 

Summon  button  lights:  The  summon  buttons  can  be  illuminated  (by 
bulbs  behind  the  panels).  When  the  summon  button  interrupt  service 
routine  in  the  program  receives  an  UP  or  DOWN  button  vectored  inter¬ 
rupt,  it  should  send  a  signal  to  the  appropriate  panel  to  illuminate  the 
appropriate  button.  This  signal  is  sent  by  the  program’s  loading  the  num¬ 
ber  of  t  he  button  in  t  he  appropriate  memory-mapped  output  register,  one 
for  the  UP  buttons  and  one  for  the  DOWN  buttons.  The  illumination  of 


a  button  notifies  the  passenger(s)  that  the  system  has  taken  note  of  his 
or  her  request  and  also  prevents  further  interrupts  caused  by  additional 
pressing  of  the  button.  When  the  controller  stops  an  elevator  at  a  floor, 
it  should  send  a  signal  to  the  floor’s  summon  button  panel  to  turn  off 
the  appropriate  (UP  or  DOWN)  button  for  that  floor. 

Elevator  motor  controls  (Up,  Down,  Stop):  There  is  a  memory-mapped 
control  word  for  each  elevator  motor.  Bit  0  of  this  word  commands 
the  elevator  to  go  up,  bit  1  commands  the  elevator  to  go  down,  and 
bit  2  commands  the  elevator  to  stop  at  the  floor  whose  sensor  swfitch 
is  closed.  The  elevator  mechanism  will  not  obey  any  inappropriate  or 
unsafe  command.  If  no  floor  sensor  switch  is  closed  when  the  compute'- 
issues  a  stop  signal,  the  elevator  mechanism  ignores  the  stop  signal  until 
a  floor  sensor  switch  is  closed.  The  computer  program  does  not  have 
to  worry  about  controlling  an  elevator’s  doors  or  stopping  an  elevator 
exactiy  at  a  level  (home)  position  at  a  floor.  The  elevator  manufacturer 
uses  conventional  switches,  relays,  circuits,  and  safety  interlocks  for  these 
purposes  so  that  the  manufacturer  can  certify  the  safety  of  the  elevators 
without  regard  for  the  computer  controller.  For  example,  if  the  computer 
issues  a  atop  command  for  an  elevator  when  it  is  within  eight  inches  of  a 
floor  (so  that  its  floor  sensor  switch  is  closed),  the  conventional,  approved 
mechanism  stops  and  levels  the  elevator  at  that  floor,  opens  and  holds 
its  doors  open  appropriately,  and  then  closes  its  door.  If  the  computer 
issues  an  up  or  down  command  during  this  period  (while  the  door  is 
open,  for  example),  the  manufacturer's  mechanism  ignores  the  command 
until  its  conditions  for  movement  are  met.  (Therefore,  it  is  safe  for  the 
computer  to  issue  an  up  or  down  command  while  an  elevator’s  door  is  still 
open.)  One  condition  for  an  elevator’s  movement  is  that  its  stop  button 
not  be  depressed.  Each  elevator’s  destination  button  panel  contains  a 
stop  button.  This  button  does  not  go  to  the  computer.  Its  sole  purpose 
is  to  hold  an  elevator  at  a  floor  with  its  door  open  when  the  elevator 
is  currently  stopped  at  a  floor.  A  red  emergency  stop  switch  stops  and 
holds  the  elevator  at  the  very  next  floor  it  reaches  irrespective  of  computer 
scheduling.  The  red  switch  may  also  turn  on  an  audible  alarm.  The  red 
switch  is  not  connected  to  the  computer. 

Target  machine:  The  elevator  scheduler  and  controller  may  be  imple¬ 
mented  for  any  contemporary  microcomputer  capable  of  handling  this 
application. 


I  he  specification  of  this  problem  produced  with  the  OOA  method  is  included 
as  appendix  A. 

I 
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5.2  Results  of  Applying  the  OOA  Method 

5.2.1  Comparison  With  Method  Goals.  The  initial  goals  of  the  OOA  method 
were  outlined  in  section  3.1.  These  goals  are  summarized  below,  and  examined  with 
respect  to  the  application  of  the  method. 

5. 2. 1.1  Gravhical  Nature  Of  Tools.  The  tools  of  the  method  should  In 
primarily  graphical ,  with  a  notation  that  can  be  understood  by  domain  experts  with 
little,  initial  training. 

The  OOA  method’s  communication  with  the  domain  expert  is  done  predom¬ 
inately  through  concept  maps  (graphical),  story  boards  (graphical  with  support¬ 
ing  text),  and  an  event /response  list  (textual).  Each  of  these  tools  is  fairly  un¬ 
structured,  with  simple,  flexible  notation  that  requires  little  training  to  under¬ 
stand.  The  fact  that  concept  maps  were  used  by  elementary  school  children  as 
a  means  of  communicating  understanding  attests  to  their  shallow  learning  curve 
[Novak  and  Gowin,  1984].  The  text  in  the  story  boards  and  event /response  list  is 
presented  in  short  statements,  making  it  easier  for  a  reader  to  follow.  Not  only 
should  the  domain  expert  be  able  to  readily  understand  this  material,  he  may  well 
be  able  to  prepare  the  items  in  phase  I  of  the  method  himself. 

The  more  structured  object  encyclopedia  entries  will  still  be  reviewed  by  the 
domain  expert(s),  and  thus  need  to  be  easily  understood.  The  contents  of  the  en¬ 
tries  rely  heavily  on  the  graphical  structure  diagram,  interface  diagram,  and  state 
transition  diagram.  The  syntax  of  these  diagrams  is  similar  to  that  of  the  concept 
map,  so  they  too  should  allow  the  reader  to  concentrate  more  on  the  meaning  of  the 
diagram  rather  than  the  syntax. 

5.2. 1.2  Ease  of  Application.  The  method  should  be  stnin/h tfo rwanl  in 
its  application. 

The  OOA  method  includes  some  heuristics  to  apply  the  steps  of  the  met  hud. 
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Once  the  initial  information  is  gathered  from  the  domain  expert  (phase  I  of  the 
method),  each  of  the  steps  taken  to  structure  the  information  and  create  object 
encyclopedia  entries  is  based  on  information  present  from  phase  I. 

One  of  the  more  difficult  aspects  of  applying  the  OOA  method  is  the  necessity 
to  iterate  between  some  of  the  steps  in  the  method.  For  example,  in  the  application 
of  the  method  to  the  elevator  problem,  the  similarity  between  the  UP  and  DOWN 
request  panels  and  each  elevators  control  panel  was  not  evident  until  these  classes 
were  documented  as  entries  in  the  object  encyclopedia.  Recognition  of  their  parallel 
characteristics  required  the  revision  of  the  preliminary  object  list  (page  A-30)  and 
the  object  encyclopedia  entry  for  the  control  panel  (page  A-48). 

5.2. 1.3  Identification  of  Objects,  Attributes,  and  Object  Interaction.  The 
method  should  support  the  identification  of  objects,  their  attributes,  and  the  inter¬ 
action  among  objects.  This  necessarily  includes  documenting  the  object  's  external 
interface. 

The  method  supports  the  identification  of  objects  and  their  attributes  from  the 
concepts  on  the  domain  expert’s  concept  maps.  The  identification  of  the  interaction 
among  objects,  or  messages  passed  between  them,  is  supported  by  the  method  via  the 
event/response  list,  as  well  as  the  linking  verbs  on  the  concept  maps  The  objects, 
attributes,  and  interaction  among  objects  is  further  documented  for  each  class  of 
objects  in  the  series  of  entries  in  the  object  encyclopedia. 

The  key  to  identifying  the  objects  and  messages  in  the  OOA  method  is  in  the 
construction  of  the  concept  maps,  story  boards,  and  event /response  list  in  phase  I. 
This  phase  may  require  a  considerable  effort  to  document  and  refine  the  requirements 
in  order  to  adequately  specify  the  problem. 

In  the  application  of  the  OOA  method  to  the  elevator  problem,  the  vast  major¬ 
ity  ( (id  out  of  75)  of  the  concepts  in  the  initial  concept  maps  t urned  out  to  be  direct  1  y 
related  to  objects  or  attributes  documented  in  phase  II  of  the  method.  Likewise',  all 


of  t fie  event/response  pairs  in  the  event /response  list  resulted  in  at  least  one  message 
sent  between  object  classes. 

5. 2. 1.4  Top-Down  Nature  of  Model.  The  model  of  the  system  should  be 
presented  in  a  top-down  hierarchical  manner. 

As  stated  in  chapter  III,  the  levels  of  hierarchy  in  the  description  of  the  system 
can  be  seen  through  the  interface  and  structure  diagrams  in  the  object  encyclopedia. 
As  seen  in  the  description  of  the  elevator  control  system,  the  entries  in  the  object 
encyclopedia  are  ordered  by  first  describing  the  main  object  class  ( Elevator  Control 
System),  then  its  component  classes  ( Elevator ,  and  Control  Panel),  before  defining 
the  remaining  classes  (in  alphabetical  order). 

The  ordering  of  classes  in  the  object  encyclopedia  is  complicated  by  the  nature 
of  object-oriented  systems;  there  is  not  always  a  clear  distinction  between  levels  of 
abstraction,  and  these  levels  are  not  as  neatly  organized  into  a  tree  structure  familiar 
in  a  functional  description  of  a  problem.  Often,  a  lower  level  class  (such  as  Weight  or 
Address  in  the  elevator  problem)  is  used  by  a  variety  of  other  classes  in  the  system. 
Also,  an  object  of  a  certain  class  may  send  messages  to  other  objects  at  different 
levels  of  abstraction.  For  example,  the  interface  diagram  for  the  Control  Panel  class 
(see  figure  A. 30)  shows  that  a  control  panel  object  may  send  messages  to  higher  level 
objects  (via  the  Button  Pushed  message),  or  lower  level  objects  (e.g.  Address,  or  an 
Input  Register).  To  further  compound  the  problem,  objects  of  the  Control  Panel  class 
may  appear  at  different  levels  of  abstraction.  The  UP  and  DOWN  Request  Panels  are 
logical  components  of  the  overall  Elevator  Control  System,  while  an  elevator  control 
panel  is  a  component  of  the  Elevator  class.  These  complexities  make  it  difficult  to 
hierarchically  order  the  descriptions  of  the  object  classes  in  the  object  rnryclopi  ilia. 
It  was  these  complexities  which  prompted  the  idea  for  the  traversal  of  classes  through 
the  structure  and  interface  diagrams  via  the  OOA  tool  described  in  chapter  1\  . 


5.2. 1.5  Support  for  Large ,  Embedded  Systems.  The  method  should  sup¬ 
port  the  definition  of  large  embedded  systems. 

The  application  of  the  00A  method  to  the  elevator  problem  demonstrates  the 
ability  of  the  method  to  document  the  requirements  for  an  embedded  system.  Indeed, 
the  event /response  list,  frequently  used  in  the  analysis  of  embedded  systems,  proved 
effective  in  identifying  messages  between  objects  in  the  OOA  method.  However, 
few  software  engineers  would  consider  the  elevator  problem,  though  not  trivial,  to 
be  a  “large'1  embedded  system.  Larger  problems  require  the  ability  of  the  analyst 
to  present  the  details  of  the  system  in  a  hierarchical  manner.  Though  not  proven 
decisively  in  the  example  included  here,  the  OOA  method  and  tool  has  the  ability 
to  provide  such  hierarchical  structuring,  as  discussed  in  the  previous  section. 

5.2. 1.6  Minimal  Redundancy.  Different  method  representations  should 
include  minimal  redundancy  between  them. 

The  second  phase  of  the  OOA  method  contains  a  great  deal  of  the  information 
captured  in  phase  I.  However,  this  is  expected  since  one  phase  follows  from  the 
other,  with  the  different  phases  aimed  at  communication  with  different  audiences. 
Potentially  harmful  redundancy  occurs  when  different  views  within  the  same  phase 
of  the  method  needlessly  contain  overlapping  information.  Some  redundancy  exists 
in  all  methods  where  the  same  entity  is  viewed  from  multiple  views.  This  redundant 
information  is  difficult  to  keep  current  when  changes  are  made  to  one  view  of  the 
entity. 

In  phase  I  of  the  OOA  method,  an  indication  of  a  message  between  objects 
may  show  up  in  each  of  the  event /response  list,  story  boards,  and  action  verb  links 
on  the  concept  maps.  However,  each  of  these  views  contains  different  information 
about  the  messages.  The  event/response  list  describes  the  message  as  well  as  any 
response  that  is  undertaken  as  a  result  of  receiving  the  message.  The  concept  map 
describes  the  message  in  terms  of  its  relationship  with  its  sender  and  receiver.  The 
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story  boards  place  the  message  in  context  with  other  messages  and  the  state  of  the 
entities  in  the  system.  Thus,  while  the  existence  of  a  message  may  be  known  from 
different  views,  each  of  these  views  contains  different  information  about  the  message. 

In  phase  II  of  the  00A  method,  there  is  some  redundancy  in  the  information 
provided  on  the  interface  diagrams.  The  messages  that  show  up  leaving  one  entity 
must  show  up  in  the  interface  diagram  of  the  receiving  entity.  For  example,  the 
Direction  Of  message  from  the  Elevator  Control  System  class  to  the  Elevator  class 
must  show  up  on  the  interface  diagram  (figure  A. 24)  and  messages  sent  list  (page  A- 
36)  of  the  Elevator  Control  System ,  as  well  as  the  interface  diagram  (figure  A. 27) 
and  messages  received  list  (page  A-41)  of  the  Elevator  class.  However,  the  repetition 
is  inevitable  if  the  requirements  specification  is  organized  such  that  the  description 
of  each  class  is  localized.  This  organization  makes  it  easier  to  map  the  analysis  into 
an  object-oriented  design. 

Thus,  while  there  is  some  replication  in  the  information  contained  in  different 
diagrams  in  phase  II,  this  redundancy  is  minimal  and  is  caused  by  attempts  to 
satisfy  other  goals.  The  redundancies  that  do  exist  can  be  exploited  by  the  OOA 
tool  presented  in  chapter  IV  to  check  the  consistency  of  the  object  classes  with  each 
other. 

5.2.1. 7  Mapping  Into  OOD.  The  result  of  the  method  should  map  cleanly 
into  a  ''Booch -flavored"  object-oriented  design. 

Viewing  the  entries  in  the  object  encyclopedia  for  the  elevator  problem,  tin' 
mapping  into  an  object-oriented  design  is  fairly  obvious.  F.ach  documented  class 
of  objects  in  the  object  encyclopedia  (except  for  the  external  entities  that  have  no 
software  driver)  will  likely  show  up  as  objects  in  the  design.  Also,  each  of  the  docu¬ 
mented  classes  contains  enough  information  about  the  class's  behavior  and  external 
interface  to  design  the  class. 
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5.2.2  Comparison  With  Other  Analysis  Approaches.  The  “elevator  prob¬ 
lem"  has  been  used  to  illustrate  other  analysis  tools,  including  [Yourdon,  1989]  and 
[EVB,  1989],  This  enables  a  comparison  of  the  00 A  method  to  these  methods  as  a 
precursor  to  object-oriented  design. 

5.2.2. 1  Modern  Structured  Analysis.  Although  Yourdon  makes  no 
claims  as  to  the  applicability  of  Modern  Structured  Analysis  as  a  precursor  to  object- 
oriented  design,  Booch  maintains  that  data  flow  diagrams  (even  developed  with  a 
functional  approach)  are  appropriate  to  capture  the  problem  space  for  an  object- 
oriented  design  [Booch,  1986:212).  Also,  the  abstraction  analysis  process  proposed 
by  [Seidewitz  and  Stark,  1987]  begins  with  the  data  flow'  diagrams  produced  during 
structured  analysis. 

The  high  level  data/control  flow  diagrams  for  the  elevator  problem,  taken  from 
[Yourdon,  1989],  are  shown  in  figures  5.1  through  5.4.  These  diagrams  provide  a  feel 
for  how  the  problem  is  modeled  using  Modern  Structured  Analysis. 

Looking  at  the  these  figures,  it  becomes  readily  apparent  that  the  data/control 
flow  diagrams  do  not  map  well  into  an  object-oriented  design.  While  some  of  the 
lower-level  objects  can  be  discerned  from  the  data  stores,  it  is  more  difficult  to 
identify  the  mid-level  objects.  Furthermore,  the  messages  sent  and  received  by  each 
object  are  not  obviously  grasped  from  a  single  data  flow  diagram.  A  significant 
amount  of  additional  effort  must  be  applied  to  transform  these  data/control  flow 
diagrams  (as  in  [Seidewitz  and  Stark,  1987])  into  a  specification  appropriate  for  an 
object-oriented  design. 
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Seliedule  and  Control  Elevator: 
[Yonrdon,  1989:638] 
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Elevator  Essential 


I'  igure  5.2.  Store  and  Display  Request  [Yourdon.  1080:03!)] 
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Figure  o.3.  Control  KJrvator  [bourdon.  1  1  .’J] 
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5. 2. 2. 2  FVB's  Object-Oriented  Requirements  Specification.  The  OOA 
method  presented  in  this  thesis  produces  a  model  with  some  similarities  to  E\  B  - 
Object-Oriented  Requirements  Specification  (see  section  2.3. 2.1).  The  closest  resem¬ 
blance  comes  in  the  use  of  a  multi-dimensional  view  of  each  class  of  objects.  I  lie 
object  encyclopedia  entries  presented  here  share  many  common  characteristics  with 
EVB's  object  class  specification  (OCS). 

Despite  the  similarities  between  the  two  specifications,  there  are  some  funda¬ 
mental  differences  in  two  approaches.  First,  the  EVB  approach  provides  few  guide¬ 
lines  for  ident  ifying  object  classes  and  developing  the  set  of  object  class  specifications. 
EVB  provides  some  “hints"  for  starting  an  object-oriented  requirements  analysis, 
both  from  scratch  and  from  an  existing  set  of  requirements,  but  these  "hints"  are 
not  developed  into  a  set  of  specific  steps  and  heuristics  to  guide  the  analyst.  The 
steps  of  OOA  method  presented  in  this  thesis  attempt  to  provide  the  analyst,  with  a 
more  deliberate  approach  to  modeling  the  system  requirements. 

The  OOA  method  recognizes  a  need  for  communication  with  both  domain  ex¬ 
perts  and  designers.  The  object  encyclopedia  entries  (and  EVB  OCSs)  are  structured 
representations  aimed  at  presenting  information  to  the  designer.  The  OOA  method 
also  includes  valuables  tools  for  communication  with  the  domain  expert(s).  The 
concept  maps,  story  boards,  and  event /response  list  provide  a  more  iinstruct nn  <1 
representation  of  the  system  which  is  often  easier  for  the  domain  expert  to  follow 
(and  construct ).  and  also  serves  as  a  basis  for  the  more  structured  models. 

The  organization  of  the  OCSs  in  EVB’s  approach  is  based  primarily  on  the 
class's  potential  for  reuse.  While  the  method  of  this  thesis  recognizes  the  poten¬ 
tial  of  reusable  components,  it  places  more  consideration  in  the  ordering  ot  class 
descriptions  based  on  the  system  hierarchy,  especially  through  the  use  of  the  OOA 
t  ool . 

f  inally,  t  lie  OOA  method  contains  an  interlace  diagram  in  the  object  nicyrlo- 
ptelia  entries.  This  diagram,  lacking  in  the  EV  B  OCS,  provides  a  graphical  view  oi 
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the  class  in  terms  of  the  messages  sent  to  and  received  by  other  classes.  This  diagram 
can  provide  a  valuable  insight  at  a  glance  into  the  interaction  among  object  classes 
in  the  system. 

5.3  Conclusion 

The  application  of  the  object-oriented  analysis  method  on  the  elevator  prob¬ 
lem  demonstrates  the  viability  of  the  method  in  analyzing  the  requirements  of  an 
embedded  software  system.  The  combination  of  the  concept  maps,  story  boards,  and 
event /response  list  captures  both  the  problem  elements  and  their  interaction,  in  an 
unstructured  format  readily  understandable  by  the  domain  experts.  In  addition,  the 
metnod's  structuring  of  this  information  into  object  encyclopedia  entries  provides  a 
more  straightforward  mapping  into  an  object-oriented  design  than  a  more  traditional 
(functional)  analysis  method. 


VI.  Conclusions  and  Recommendations 


The  final  chapter  of  this  thesis  begins  with  a  summary  of  the  goals  and  ob¬ 
jectives  which  guided  this  research.  Next,  conclusions  are  presented  based  on  the 
investigation  into  and  application  of  object-oriented  analysis  techniques.  The  chap¬ 
ter  concludes  with  a  list  of  areas  recommended  for  further  research  'allowing  from 
this  study. 

6.1  Summary 

The  main  goal  of  this  thesis  was  to  develop  an  Object-Oriented  Analysis  (00A  j 
method  to  model  software  requirements  as  a  precursor  to  object-oriented  design.  The 
research  was  in  part  inspired  by  the  work  of  [Barnes,  1988],  who  recommended  tin- 
use  of  the  concept  map  as  a  tool  to  replace  the  informal  strategy  as  a  representation 
of  the  problem  space. 

This  thesis  was  guided  by  the  series  of  objectives  outlined  in  chapter  I.  The  first 
objective  was  to  determine  the  requirements  of  an  object-oriented  analysis  method 
in  terms  of  the  information  the  method  should  capture.  These  requirements  were 
gathered  by  reviewing  the  existing  literature.  The  topics  covered  by  this  examina¬ 
tion  included  the  application  of  object-oriented  techniques  to  the  coding  and  design 
phases  of  the  life  cycle,  as  well  as  various  approaches  to  requirements  analysis. 

The  next  objective  was  to  define  the  steps  which  would  specify  the  OOA 
method.  These  steps  were  defined  by  first  selecting  the  tools  needed  to  represent  t  in- 
information  deemed  appropriate  during  OOD,  as  identifier!  in  the  literature  review. 
1  he  OOA  method  viewed  the  requirements  analysis  process  as  a  bridge  of  communi¬ 
cation  between  domain  experts  and  a  designer.  In  light  of  this,  the  method  tools  wen- 
selected  to  be  straightforward  in  syntax  (so  that  domain  experts  wouldn't  ho  over¬ 
whelmed  with  unfamiliar  symbols),  yet  structured  in  final  form  (so  that  the  designer 
wouldn't  be  overwhelmed  with  problem  complexity).  Concept  maps,  story  boards. 
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and  an  event/response  list  capture  the  software  requirements  from  the  domain  ex¬ 
pert.  A  series  of  entries  in  the  object  encyclopedia  for  each  class  of  objects  serves 
to  communicate  the  analysis  to  the  designer.  The  specific  method  steps  evolved, 
through  application  on  various  sample  problems,  to  traverse  from  one  representation 
to  the  other. 

The  OOA  method  was  then  examined  to  see  how  it  could  benefit  from  au¬ 
tomated  support.  Decision  Support  System  (DSS)  concepts  were  applied  to  define 
the  nature  of  a  tool  to  support  the  OOA  method.  The  greatest  areas  of  potential 
support  would  be  the  tool’s  ability  to  traverse  the  hierarchy  of  object  encyclopedia 
entries,  and  perform  consistency  checks  on  the  model  of  software  requirements. 

The  final  objective  was  to  validate  the  concepts  of  this  research  by  applying 
the  OOA  method  to  a  sample  problem.  The  method  was  evaluated  with  respect  to 
the  initial  method  goals,  and  the  results  of  the  analysis  compared  to  those  obtained 
through  other  methods. 

6.3  Conclusions 

The  concept  map  is  a  viable  tool  for  identifying  objects  and  classes  of  objects 
in  'he  problem  space.  The  informal  syntax  of  the  concept  map  makes  it  ideal  for 
communication  between  an  analyst  and  a  domain  expert.  However,  it  is  not  sufficient 
for  specifying  the  entire  problem.  The  concept  map  is  useful  for  showing  structural 
relationships  among  objects,  but  is  weak  for  describing  the  dynamic  interaction 
among  objects.  Therefore,  the  concept  map  must  be  used  in  conjunction  with  other 
tools  (such  as  story  boards  and  the  event/response  list)  to  fully  capture  the  breadth 
of  information  required  during  object-oriented  design. 

I  he  complex  nature  of  an  object  requires  a  sophisticated  set  of  tools  to  rep¬ 
resent  the  information  needed  to  design  it.  An  object  contains  elements  from  both 
the  information  and  functional  domains,  and  cannot  be  fully  characterized  by  one 
view  alone.  Iraditional  functional  analysis  tools,  such  as  the  data  flow  diagram. 


are  therefore  not  sufficient  in  themselves  to  adequately  represent  objects  since  they 
concentrate  on  only  one  dimension.  Furthermore,  even  when  these  tools  are  used  in 
combination  with  other  tools  which  capture  the  missing  dimension,  they  are  often 
unclear  to  the  designer  because  they  lack  a  one-to-one  mapping  between  objects  and 
entities  on  the  diagram. 

Perhaps  the  most  significant  innovation  resulting  from  this  thesis  is  the  use  of 
the  event/response  list  in  identifying  messages  passed  between  objects.  This  vehicle 
provides  a  description  of  the  interaction  of  the  software  to  its  external  environment. 
Each  external  event  in  the  list  (excluding  periodic  events)  corresponds  to  a  message 
passed  to  a  particular  object.  The  responses  to  these  events  suggest  the  existence  oi 
additional  messages  passed  between  objects. 

A  somewhat  surprising  conclusion  is  that  the  functional  and  object-oriented 
views  may  not  be  as  detached  as  Booch  seems  to  imply.  At  the  highest  levels  of 
abstraction,  an  actor  object’s  state  may  be  composed  entirely  of  the  states  of  its 
component  objects.  At  this  level,  it  becomes  difficult  to  distinguish  between  an 
actor  object  and  a  process.  Often,  the  distinction  is  more  one  of  nomenclature 
rather  than  substance,  as  in  the  difference  between  an  “elevator  scheduler"  object 
and  a  “schedule  elevator”  process. 

Finally,  an  interesting  observation  resulting  from  this  research  deals  with  the 
topology  of  an  object-oriented  design  verses  that  of  a  structured  design.  The  result 
of  applying  structured  design  is  typically  a  tree-shaped  network  of  modules  in  a 
structure  chart.  The  set  of  sub-modules  which  compose  the  parent  module  (those 
which  stern  from  it  on  a  structure  chart)  is  identical  to  the  set  of  modules  the  parent 
calls.  On  the  other  hand,  the  topology  of  an  object-oriented  design  is  more  like 
that  of  a  directed  graph.  In  an  object-oriented  design,  the  set  of  objects  receiving 
messages  from  a  particular  object  is  potentially  greater  than  the  set  of  sub-objects 
which  compose  that  object.  In  other  words,  unlike  a  module  in  a  structured  design, 
it  is  not  unusual  for  an  object  to  interact  with  other  objects  at  the  same  (or  even 
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higher)  level  of  abstraction.  This  characteristic  makes  it  more  difficult  to  distinguish 
between  levels  of  abstraction  in  an  object-oriented  design  than  in  a  structured  design. 

6.3  Recommendations 

First,  and  foremost,  the  00A  tool  should  be  designed  and  implemented  to 
further  apply  and  test  the  OOA  method  developed  in  this  thesis.  The  availability  of 
a  software  tool  to  assist  in  the  application  of  the  method  not  only  would  make  it  easier 
to  apply  the  OOA  method,  but  would  also  facilitate  the  analysis  of  larger  systems. 
With  this  experience,  further  evaluation  of  these  concepts  can  be  undertaken.  The 
description  of  the  tool  presented  in  chapter  IV  provides  a  basis  for  the  design  and 
implementation  of  the  tool. 

A  more  comprehensive  evaluation  of  the  OOA  method  should  be  performed. 
This  thesis  demonstrated  an  approach  to  an  object-oriented  analysis  of  the  problem 
space  that  intuitively  seems  more  appropriate  for  use  with  OOD.  However,  the  true 
benefit  of  a  good  approach  to  requirements  analysis  is  not  seen  until  later  in  the 
project  life  cycle,  when  analysis  errors  can  have  a  great  impact  on  the  quality  of  the 
software.  Further  evaluation  should  compare  the  results  of  this  method  to  that  ol 
other  methods,  not  only  during  tho  analysis  phase,  but  throughout  the  project's  lilt? 
cycle. 

More  research  needs  to  be  done  into  the  practical  aspects  of  applying  object- 
oriented  design  to  real-time  embedded  systems.  Issues  such  as  interrupt  handling  and 
concurrency  are  not  emphasized  by  Booch  in  his  definition  of  object-oriented  design. 
I  he  presence  of  distributed  processing  in  many  such  applications  makes  concurrency 
an  especially  important  issue.  To  date,  few  guidelines  exist  to  assist  a  designer  in 
introducing  coneurrency  into  an  object-oriented  design.  This  may  be  a  result  ol 
the  limitations  of  traditional  object-oriented  languages  (e.g.  Smalltalk)  which  lack 
features  to  manage  concurrent  processing.  The  existence  of  tasking  in  Ada.  however, 
enables  the  implementation  of  concurrent  object-oriented  programs.  Potentially,  all 


objects  in  a  system  could  execute  concurrently;  however,  efficiency  considerations 
impose  limits  on  this  strategy.  Further  research  needs  to  be  undertaken  to  provide 
heuristics  for  employing  concurrency  in  the  object  oriented  paradigm. 

An  interesting  observation  during  the  course  of  this  research  calls  for  further 
investigation.  In  Booch’s  definition  of  object-oriented  design  as  it  applies  to  Ada. 
an  object  presents  a  uniform  interface  to  all  who  have  visibility  to  it.  Objects  may 
receive  the  same  messages  from  other  objects,  whether  they  are  at  higher,  lower,  or 
the  same  level  of  abstraction.  However,  the  information  hiding  principle  seems  to 
warrant  a  different  view  of  the  object  from  different  levels  of  abstraction.  Further 
research  can  provide  an  insight  into  what  avenues,  if  any,  should  be  taken  to  give  an 
object  greater  flexibility  in  presenting  its  interface  to  different  levels  of  abstraction. 

One  of  the  assumptions  of  the  00 A  method  was  that  the  domain  expert  has 
previously  defined  the  software  requirements;  the  analysis  method  only  captures 
those  requirements  and  adds  structure  to  them  for  the  design  activity.  Further 
research  needs  to  be  done  in  the  psychological  and  procedural  aspects  of  constructing 
the  initial  concept  maps,  story  boards,  and  event/response  lists  to  define  a  complete 
set  of  requirements. 

Finally,  the  issue  of  reusability  needs  to  be  addressed.  One  of  the  potential 
benefits  of  the  object-oriented  paradigm  is  in  the  reuse  of  object  classes.  After  all. 
the  set  of  predefined  classes  is  one  of  the  key  strengths  of  object-oriented  languages 
such  as  Smalltalk  and  Actor.  The  issue  of  reuse  seems  to  warrant  application  at 
the  organizational  level  as  well  as  the  project  level.  Clearly,  the  .search  for  reusable 
components  should  be  undertaken  at  the  project  level,  during  the  analysis  or  design 
activities.  However,  the  decision  to  expend  the  additional  resources  required  to  de¬ 
sign  a  component  to  be  reusable  is  not  as  clear — this  decision  is  as  much  managerial 
as  technical,  and  is  influenced  by  the  requirements  of  other  projects  in  the  organiza¬ 
tion.  Currently,  the  object  encyclopedia  entries  contain  an  assessment  of  the  class's 
reuse  potential.  The  advancement  of  a  more  complete  framework  for  identifying. 


designing,  and  applying  reusable  object  classes  needs  to  be  investigated. 

6.4  Closing  Remarks 

The  successful  application  of  object-oriented  design  depends  on  a  complete 
model  of  software  requirements.  The  object-oriented  analysis  method  presented  in 
this  thesis  constructs  such  a  model.  Furthermore,  the  information  contained  in  this 
model  is  structured  around  the  objects  in  the  problem  space.  This  organization  fur¬ 
nishes  a  more  straightforward  mapping  into  OOD  than  functional  analysis  methods 
such  as  Structured  Analysis.  The  OOA  method  also  provides  more  guidelines  and 
structure  for  the  designer  than  the  informal  strategy  method  originally  proposed  by 
Booch,  while  striving  to  maintain  a  more  unstructured,  graphical  means  of  commu¬ 
nication  with  the  domain  experts.  The  OOA  method  presented  here  yields  a  basis 
for  application  and  further  study  in  object-oriented  requirements  analysis,  object- 
oriented  design,  and  the  proper  use  of  Ada  language  constructs. 
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Appendix  A.  Analysis  of  an  Elevator  Control  System 


A.  I  Purpose  of  Elevator  Control  System 

The  purpose  of  the  elevator  control  system  is  to  schedule  and  control  four 
elevators  in  a  building  with  40  floors.  The  elevators  will  be  used  to  carry  people 
from  one  floor  to  another  in  the  conventional  way. 

The  elevator  control  system  receives  signals  from  summons  panels  on  each 
floor,  and  command  panel  buttons  and  floor  sensors  associated  with  each  elevator. 
It  controls  the  movement  of  the  elevators  and  the  setting  of  lights  on  the  summons 
panels  and  elevator  control  panels. 

The  elevator  control  system  will  only  control  the  movement  of  the  elevators 
from  floor  to  floor.  The  computer  program  does  not  have  to  worry  about  controlling 
an  elevator's  doors  or  stopping  an  elevator  exactly  at  a  level  (home)  position  at  a 
floor.  The  elevator  manufacturer  uses  conventional  switches,  relays,  circuits,  and 
safety  interlocks  for  these  purposes  so  that  the  manufacturer  can  certify  the  safety 
of  the  elevators  without  regard  for  the  computer  controller.  For  example,  if  the' 
computer  issues  a  stop  command  for  an  elevator  when  it  is  within  eight  inches  of 
a  floor,  the  conventional,  approved  mechanism  stops  and  levels  the  elevator  at  that 
floor,  opens  and  holds  its  doors  open  appropriately,  and  then  closes  its  door,  ll 
the  computer  issues  an  up  or  down  command  during  this  period  (while  the  door  is 
open,  for  example),  the  manufacturer’s  mechanism  ignores  the  command  until  its 
conditions  for  movement  are  met. 

I.J  Court  pi  Maps 

The  concept  maps  on  the  following  pages  describe  I  lie  components  of  the  ele¬ 
vator  (  ontrol  svsfem. 
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Figure  A. 2.  Scheduling  Algorithm 


Figure  A.  1.  Elevator  Motor 


Figure  A. 5.  Elevator  Floor  Sensors 


A-G 


vveigni 

Sensor 


Figure  A. 8.  Elevator  Weight  Sensor 
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Figure  A. 9.  Elevator  Request  Panel 
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A.  3  Story  Boards 

The  story  boards  on  the  following  pages  describe  some  of  the  situations  that 
the  elevator  control  system  will  face.  The  story  boards  show':  1)  the  status  of  one 
of  die  four  elevators  (including  the  location  and  control  panels,  direction  of  travel. 
motor  commands,  etc.);  2)  the  up  and  down  request  panel  buttons  from  each  of  the 
floors;  and  3)  the  scheduling  algorithm’s  list  of  outstanding  summons  requests. 
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Lach  of  the  four  elevators  has  a  location  panel  (showing  where  the  elevator  currently  is)  and  a  ’'on.tr- >i  pun>i 
with  buttons  for  the  passengers  to  enter  their  destination  floor.  Lights  behind  the  buttons  are  lit  when  the  button 
is  pressed.  Also  associated  with  an  elevator  are  a  direction  of  travel,  commands  to  the  elevator’s  motor,  a  *»ens.i|- 
signalling  which  floor  the  elevator  is  approaching,  an  overweight  sensor,  and  a  list  of  destination  floors  selected  by 
the  elevator’s  passengers. 

Ihe  request  panels  contain  buttons  for  passengers  to  summon  an  elevator.  The  UP  Request  Panel  contains 
buttons  on  all  floors  except  floor  40.  Likewise,  the  DOWN  Request  Panel  contains  buttons  on  all  floors  e\,-ept 
Hoot  1.  I  he  passenger  will  press  the  button  on  either  the  UP  or  DOWN  Request  Panels,  depending  on  his  <1-  "ii»  1 
dit'-'  t  ion  of  travel.  I  he  buttons  have  lights  behind  them  which  are  lit  when  the  button  is  pressed. 

I  h'v  fl/mtnr  control  system  maintains  a  list  of  outstanding  requests  from  the  request  panels,  which  H  M'-  ^  t  > 
-mb'  dole  '‘levators  to  respond  to  these  requests. 

An  idle  -  levator  is  characterized  by  having  “parked”  as  its  direction.  In  tills  case,  elevator  1  is  parked  at  ff-.-  i 
t  .(Mailing  a  -  otntnand  from  the  elevator  control  system  to  respond  to  a  summons  request. 


Figure  A. 10.  Story  Board:  Idle  Elevators 


A- 1 2 


Elevator  1  (of  4) 

Location  Panel 

6666666... 

66 

3666666... 

68 

Direction:  Up 

Motor  Command:  Up 

Floor  Sensor:  At  Floor  1 

Overweight:  No 

Destination  List:  — 


Control  Panel 

O©  Q© 
Q  ©  0  © 


U p  Down 

Request  Request 


Floor  40: 
Floor  39: 

Floor  7: 
Floor  6: 
Floor  5: 
Floor  4: 
Floor  3: 

Floor  2: 
Moor  1: 


Panel 

Pane. 

o 

o 

o 

o 

o 

o 

o 

o 

o 

o 

o 

o 

© 

o 

o 

o 

o 

o 

Elevator 
Scheduler 

Outstanding 

Rermests 


3U 


I  Ji'*  I  P  Inquest  Panel  button  on  floor  3  is  pressed.  The  elevator  control  system  will: 

•  illuminate  (he  light  behind  the  “tip”  button  of  the  request  pane)  on  floor  3. 

•  add  the  request  (3U)  to  the  list  of  outstanding  requests. 

•  pick  an  Hevnlor  to  respond  to  the  request.  Since  all  elevators  are  current  lv  idle,  the  closest  elevator  t .  >  tin 
summons  (in  this  rase  elevator  1  )  is  sent. 

•  issue  an  “up"  command  to  elevator  l . 

•  set  elevator  1  *s  direction  to  dip". 

Figure  A. 11.  Story  Hoard:  Up  Request  from  Floor  3 
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■  •I  tor  1  •”3»tor  '  .g nai  -t  «»  „»*c-  c-  /it'  -  iloor  2.  1 1 

extinguish  the  light  for  floor  1  on  the  location  panel  of  elevator  1. 
illuminate  the  light  for  floor  2  on  the  location  panel  of  elevator  1. 


floor  2.  The  eleval.»r  co,.*rol  system  will 


Figure  A.  12.  Story  Board:  Hlevator  Arrives  at  Floor  2 
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•  extinguish  file  light  for  floor  2  on  the  location  panel  of  elevator  1. 

•  illuminate  the  light  for  floor  3  on  the  location  panel  of  elevator  I. 

•  issue  a  "stop”  command  to  elevator  I. 

•  extinguish  the  light  behind  the  button  on  floor  3  of  the  I.'P  Bequest  Panel. 

•  i  <‘move  the  3l  request  from  the  scheduling  algorithm’s  list  of  outstanding  requests. 


ligure  A. 13.  Story  Hoard:  Elevator  Arrives  at  Floor  3 
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I  l »' •  passenger  presses  the  button  for  floor  22  on  the  control  panel  in  elevator  l.  The  elevator  control  system 


•  illuminate  the  light  behind  button  22  on  the  control  panel  for  elevator  1. 

•  add  floor  22  to  the  destination  list  for  elevator  1. 

•  issue  an  •■up"  command  to  elevator  1. 

A  -  *dr  v  at  or  1  rises,  its  floor  sensors  will  signal  the  elevator  control  system  to  change  the  lights  on  elevator  1’s  l<  ><  .it  i  >  •  1 1 
pan*-)  an  ordinplv,  as  in  the  story  board  in  figure  A. 3. 

l  iuui'  A. 11  Story  Board:  Passenger  Presses  Destination  Button 
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litmnal  elevator  summons  requests  are  issued  from  floor  5  (up)  and  floor  fi  (down).  The  elevator  control 


•  illuminate  the  light  behind  the  floor  5  button  on  the  L'P  request  panel. 

•  illuminate  the  light  behind  the  floor  6  button  on  the  DOWN  request  panel. 

•  add  the  requests  (M-  &  fiD)  to  the  list  of  outstanding  requests. 

•  |'i«  k  an  ‘‘h-vator  to  respond  to  these  requests.  Since  there  is  currently  no  elevator  heading  down,  a  park 

eh  vafor  will  be  sent,  to  respond  to  the  “f>D*’  request.  Since  elevator  1  is  heading  up  towards  floor  ~ .  it  mi 
be  able  to  handle  the  request.  However,  the  elevator  control  system  may  also  send  a  parked  ci»vat.»r 

respond  to  this  request  since  elevator  i  may  be  delayed  for  some  reason  (e.g.  overload  or  emergency  -t..| 
1  he  first  eh-vator  to  reach  floor  a  heading  up  will  respond  to  the  request. 


Figure  A. I").  Story  Hoard:  More  Summons  Requests 
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'  Mi monish  the  light  for  floor  l  on  the  location  pane!  of  elevator  1. 
illuminate  the  light  for  floor  S  on  the  location  panel  of  elevator  1. 
issm-  a  st<.p'’  command  to  elevator  I. 

Mxt  iuguish  tlie  light  behind  the  floor  a  button  of  the  1  P  request  panel. 

remove  the  "d  -  request  from  the  scheduling  algorithm's  list  of  outstanding  requests. 


1  ieurr  A. 16.  Storv  Board:  l-’ leva  tor  Arrives  at  [door  -5 
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Ih*-  passenger  presses  the  button  for  floor  3b  on  the  control  panel  in  elevator  1 .  However,  t  he  elevator  is  ovej  I.  -n  !«••!. 
I  In:  <  h  vafor  control  sy  .tem  will: 


•  illuminate  the  light  behind  button  3b  on  the  control  panel  for  elevator  1. 

•  add  floor  to  the  destination  list  for  elevator  1. 

•  periodically  (approx,  every  5  seconds)  check  the  weight  sensor  and  compare  with  the  elevator-*  tii.i\ imum 
<  apa*  it  y. 

■nice  t  he  e|*  vat  or  is  overloaded,  it  will  not  respond  to  commands  from  t  he  elevator  control  system  until  t  he  .  .vt  j  L 1 
•  -  >u>  lit  i<  <u  i'-  r**s<  >1  ved. 

Figure  A. 17.  Story  Board:  Elevator  Overload 
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Figure  A.  IS.  Story  Board:  Elevator  Load  Lightened 
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for  elevator  1  signals  arrival  of  the  elevator  at  floor  h.  Idie  elevator  control  sv^teni  wil 


vnngni'dt  •  he  light  for  floor  6  on  the  location  panel  of  elevator  1. 
ilo  innate  the  light  for  floortion  the  location  panel  <>f  elevator  1. 

•’i‘.n  of  the  summons  <»n  floor  *\  "down".  ld»*vator  1  will  not  stop  for  a  '‘down"  request  m 
•  ''mat,..*,  m  the  ‘up"  direction  Fd'vator  1  will  continue  to  rise,  its  floor  sensors  will  signal 
••  r  t  i  t-,  «  hinge  t  fie  lights  on  elevator  I  ‘s  location  panel  accordingly,  as  in  the  story  hoard  in 


f  igure  A.  19.  Store  Hoard  Elevator  Parses  Floor  ti 
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riM*r  for  '*I*-vator  1  signals  arrival  of  I  ho  elevator  at  floor  22.  The  elevat or  cont  rol  svstrm  wi 


!  ingm-di  'll#*  light  for  floor  21  on  the  location  panel  of  elevator  1. 
u/ntnafe  the  light  for  floor  22  on  the  location  panel  of  «*|e\ator  1. 

■j|'  \  ’•'t<«p“  command  to  elevator  1. 

t.runiixh  '  fie  light  behind  hiitton  22  of  the  control  panel  of  elevator  1 

I-  - 1  tii.it !■  >n  list  for  elevator  1  is  not  empty,  wait  {  M'rniiils  and  issue  an  'up''  command  to  •  h\ 


I  njure  A. 20.  Storv  Hoard:  Elevator  Arrives  at  Moor  22 


.  1 .  /  E rent /Response  List 


hvent  1:  A  passenger  issues  an  "up"  summons  from  a  particular  floor  (inter¬ 
rupt). 

Kesp.ln:  Read  the  Up  Summons  input  register  to  determine  the  floor  number 
where  the  request  was  made. 

Rib:  Illuminate  the  light  behind  the  button  on  the  UP  summons  request 
panel. 

Rlc:  If  there  is  an  idle  (parked)  elevator,  send  it  to  the  floor  where  the 
summons  was  issued. 

Rid:  Add  the  request  to  the  list  of  outstanding  requests. 

Average  response  time:  The  elevator  should  arrive  at  the  floor 
in  an  average  of  20  seconds. 

E2:  A  passenger  issues  a  "down"  summons  from  a  particular  floor  (in¬ 
terrupt). 

R2a:  Read  the  DOWN  Summons  input  register  to  determine  the  floor 
number  where  the  request  was  made. 

R2b:  Illuminate  the  light  behind  the  button  on  the  DOWN  summons 
request  panel. 

R2r:  If  there  is  an  idle  (parked)  elevator,  send  it  to  the  floor  where  the 
summons  was  issued. 

R2d:  Add  the  request  to  the  list  of  outstanding  requests. 

Average  response  time:  The  elevator  should  arrive  at  the  floor 
in  an  average  of  20  seconds. 

A  sensor  for  an  elevator  signals  its  arrival  at  a  particular  floor  (in- 
•rrnpt. ). 

Read  the  floor  number  from  the  floor  sensor  input  register  for  that 
elevator. 

Rib:  (Extinguish  the  light  on  the  location  panel  for  the  elevator  for  the 
previous  floor. 

R'ie:  Illuminate  the  light  on  the  location  panel  for  the  current  floor. 
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R3d:  If  the  floor  is  listed  in  the  destination  list  for  the  elevator,  then 
stop  the  elevator  at  the  floor  and  extinguish  the  light  behind  the 
floor  number  on  the  elevator’s  control  panel.  After  stopping,  wait  3 
seconds,  then  proceed  to  the  next  destination. 

R3e:  If  the  floor  and  direction  are  listed  in  the  outstanding  request  list, 
then  stop  the  elevator  at  the  floor.  Extinguish  the  light  behind  the 
floor  button  on  the  proper  request  panel,  and  remove  the  summons 
request  from  the  outstanding  request  list.  After  stopping,  wait  .3 
seconds,  then  proceed  to  the  next  destination. 


Maximum  response  time:  0.1  second. 


El:  A  passenger  presses  a  destination  button  on  the  control  panel  of  a 
particular  elevator  (interrupt). 

R-la:  Read  the  control  panel  input  register  to  determine  the  desired  floor 
number. 

R-lb:  Illuminate  the  light  behind  the  button  on  the  control  panel  for  the 
elevator. 

Rlc:  Add  the  floor  to  the  destination  list  for  the  elevator. 

Maximum  response  time:  0.1  second. 


E5:  An  elevator  becomes  overloaded. 

R3a:  Disable  the  elevator  so  that  it  does  not  move  until  the  overload 
condition  is  gone. 

Rob:  Periodically  (approximately  every  5.0  seconds)  check  to  see  if  the 
overload  is  eliminated. 

Maximum  response  time:  0.25  seconds. 

EG:  l  ime  to  check  elevator  weight  sensor  (periodic). 

Rfi:  If  current  weight  is  less  than  max  load,  then  respond  to  commands. 
Otherwise,  delay  another  5  seconds  and  check  the  weight  sensor 
again. 


Maximum  response  time:  2.0  seconds. 
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l.J  Known  Software  Restrictions 

The  executable  code  must  fit  in  64K  of  memory.  The  amount  of  RAM  available 
tor  data  structures  and  the  program  stack  is  limited  to  61K. 

The  elevator  control  system  should  always  respond  to  the  passenger  pushing 
a  button  on  the  control  panel  (unless  the  elevator  is  overweight,  or  the  emergence 
'top  button  is  pressed).  This  should  preclude  the  software  from  trapping  a  passenger 
inside  the  elevator.  The  elevator  car  itself  (the  hardware)  is  designed  so  that  the 
elevator  car  will  only  stop  at  a  floor. 

.1.6'  Metarequirements 

I  he  following  paragraphs  identify  domain  expert  imposed  restrictions  on  the 
design  of  the  elevator  control  system: 

1  he  program  should  schedule  the  elevators  efficiently  and  reasonably.  For 
example,  if  someone  summons  an  elevator  by  pushing  the  down  button  on  the  Court  h 
door,  the  next  elevator  that  reaches  the  fourth  floor  traveling  down  should  stop  at 
the  fourth  floor  to  accept,  the  passenger(s).  On  the  other  hand,  if  an  elevator  lias  no 
passengers  (no  outstanding  destination  requests),  it  should  park  at  the  last  floor  it 
visited  until  it  is  needed  again.  An  elevator  should  not  reverse  its  direction  of  t raved 
until  its  passengers  who  want  to  travel  in  its  current  direction  have  reached  their 
dest  inations. 

I  lie  maximum  weight  load  for  an  elevator  is  1000  pounds. 

An  address  for  a  memory  mapped  input  or  output  register  is  between  U  and 

1  he  upper  byte  is  lfi#00$. 

A  floor  number  is  implemented  in  eight  bits,  with  a  range  in  t  he  current  ole  vat  nr 
1  out  rol  'vstem  of  1 ..  10. 

1  he  elevator  weight  sensors  measure  the  weight  of  an  elevator  in  hundred'  <d 
>>'ind'.  I  he  weight  value  is  implemented  in  eight  bits,  with  a  rang*'  of  0..'_,.">.". 


Interrupt 

Number 

Elevator  1  Control  Panel 

16#01# 

Elevator  2  Control  Panel 

16#02# 

Elevator  3  Control  Panel 

16#03# 

Elevator  4  Control  Panel 

16#04# 

Elevator  1  Floor  Sensor 

16#05# 

Elevator  2  Floor  Sensor 

16#06# 

Elevator  3  Floor  Sensor 

16#07# 

Elevator  4  Floor  Sensor 

16#08# 

Up  Summons  Request  Panel 

16#0A# 

Down  Summons  Request  Panel 

16#0B# 

Note:  The  locations  given  above  were  not  provided  in  the  problem  description.  However,  this  information  w»>u)ij  b>- 
available  to  the  analyst. 

Table  A.l.  Elevator  Control  System  Interrupt  Numbers 

The  interrupt  numbers  used  for  the  hardware  signals  are  shown  in  table  A.l. 
Addresses  of  in.  ut  and  output  registers  are  shown  in  table  A. 2.  Table  A. 3  shows  the 
control  word  values  for  the  elevator  motor  control  commands 


.1.7  External  Interface  Diagram 

The  external  interface  diagram  for  the  elevator  control  system  is  shown  in 
figure  A. 7. 
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Register 

Address 

Elevator  1  Weight  Sensor  Register 

16#31# 

Elevator  2  Weight  Sensor  Register 

16#32# 

Elevator  3  Weight  Sensor  Register 

16#33# 

Elevator  4  Weight  Sensor  Register 

16#34# 

Elevator  1  Control  Panel  Input  Register 

16#35# 

Elevator  2  Control  Panel  Input  Register 

16#36# 

Elevator  3  Control  Panel  Input  Register 

16#37# 

Elevator  4  Control  Panel  Input  Register 

16#38# 

Elevator  1  Control  Panel  Output  Register 

16#39# 

Elevator  2  Control  Panel  Output  Register 

16#3A# 

Elevator  3  Control  Panel  Output  Register 

16#3B# 

Elevator  4  Control  Panel  Output  Register 

16#3C# 

Elevator  1  Floor  Sensor  Input  Register 

16#41# 

Elevator  2  Floor  Sensor  Input  Register 

16#42# 

Elevator  3  Floor  Sensor  Input  Register 

16#43# 

Elevator  4  Floor  Sensor  Input  Register 

16#44# 

Elevator  1  Location  Panel  Output  Register 

16#45# 

Elevator  2  Location  Panel  Output  Register 

16#46# 

Elevator  3  Location  Panel  Output  Register 

16#47# 

Elevator  4  Location  Panel  Output  Register 

16#48# 

Up  Summons  Panel  Input  Register 

lf>#4A# 

Down  Summons  Panel  Input  Register 

16#4B# 

Up  Summons  Panel  Output  Register 

16#  IC# 

Down  Summons  Panel  Output  Register 

16#  ID# 

Elevator  1  Motor  Control  Register 

16#51# 

Elevator  2  Motor  Control  Register 

16#52# 

Elevator  3  Motor  Control  Register 

16#  73# 

Elevator  4  Motor  Control  Register 

1 6  #34# 

N'.i**:  I  hr  addresses  given  above  were  not  provided  in  the  problem  description.  However,  this  informal  inn  wmild  be 
-t\ -lil.tble  to  tlie  analyst. 

Table  A. 2.  Elevator  Control  System  Register  Addresses 
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Table  A. 3.  Elevator  Motor  Control  Word  Format 


idlin'  A. 22.  Elevator  Control  System  External  Interface  Diagram 


.1.5  High  Level  Actor  Object  Identification 


The  elevator  control  system  is  not  complex  enough  to  he  decomposed  into  mul¬ 
tiple  actor  objects  controlling  different  problem  areas.  The  elevator  control  system 
is  documented  as  a  class  in  the  object  encyclopedia. 

A. 9  Organized  Preliminary  Object  List 


Elevator  Control  System 

Elevator 

Elevator  1 
Elevator  2 
Elevator  3 
Elevator  4 

Direction 

(Associated  with  each  elevator.) 

Floor  Sensor 

(Associated  with  each  elevator.) 

Elevator  ID 

(Associated  with  each  elevator.) 

Elevator  Motor 

(Associated  with  each  elevator.) 

Weight  Sensor 

(Associated  with  each  elevator.) 

Weight 

Current  Weight  (Associated  with  each  elevator.) 
Load  Capacity  (Associated  with  each  elevator.) 


AT) 


Control  Panel 


Elevator  Control  Panel  (Associated  with  each  elevator.) 
UP  Request  Panel 
DOWN  Request  Panel 

Location  Panel 

(Associated  with  each  elevator.) 


List 


Destination  List  (Associated  with  each  elevator.) 

Outstanding  Request  List 

Floor 

Summons  Request 
Input  Register 

Elevator  Control  Panel  Input  Register  (1  for  each  elevator) 

UP  Request  Panel  Input  Register 

DOWN  Request  Panel  Input  Register 

Floor  Sensor  Input  Register  (1  for  each  elevator) 

Output  Register 

Elevator  Control  Panel  Output  Register  (1  for  each  elevator) 
UP  Request  Panel  Output  Register 
DOWN  Request  Panel  Output  Register 

Location  Panel  Output  Register  (1  for  each  elevator) 

Address 

(Associated  with  each  input  or  output  register.) 

Interrupt  Number 

(Associated  with  each  control  panel  and  floor  sensor.) 
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A.lO  Message  Senders  and  Receivers 


Event  l:  A  passenger  issues  an  “up"  summons  from  a  particular  floor  (inter¬ 
rupt). 

Sender:  UP  Request  Panel  Receiver:  Elevator  Control  System 

Resp.la:  Read  the  Up  Summons  input  register  to  determine  the  floor  number 
of  the  request.  (Performed  by  UP  Request  Panel) 

Rib:  Illuminate  the  light  behind  the  button  on  the  UP  summons  request- 
panel .  (Performed  by  UP  Request  Panel) 

Rlc:  If  there  is  an  idle  (parked)  elevator,  send  it  to  the  floor  where  the 
summons  was  issued.  (Performed  by  Elevator  Control  System) 

Rid:  Add  the  request  to  the  list  of  outstanding  requests.  (Performed  by 
Elevator  Control  System) 

E2:  A  passenger  issues  a  “down”  summons  from  a  particular  floor  (in¬ 
terrupt). 

Sender:  DOWN  Request  Panel 
Receiver:  Elevator  Control  System 

R2a:  Read  the  DOWN  Summons  input  register  to  determine  the  floor 
number  of  the  request.  (Performed  by  DOWN  Request  Panel) 

R.2b:  Illuminate  the  light  behind  the  button  on  the  DOWN  summons 
request  panel.  (Performed  by  DOWN  Request  Panel) 

R2c:  If  there  is  an  idle  (parked)  elevator,  send  it  to  the  floor  where  the 
summons  was  issued.  (Performed  by  Elevator  Control  System) 

R2d:  Add  the  request  to  the  list  of  outstanding  requests.  (Performer!  by 
Elevator  Control  System) 

E-i:  A  sensor  for  an  elevator  signals  its  arrival  at  a  particular  floor  (in¬ 
terrupt). 

Sender:  Elevator  Floor  Sensor 
Receiver:  Elevator 

Forwarded  To:  Elevator  Control  System 

Rfla:  Read  the  floor  number  from  the  floor  sensor  input  register  for  that 
elevator.  (Performed  by  Floor  Sensor) 
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R3b:  Extinguish  the  light  on  the  location  panel  for  t'ne  elevator  for  tin* 
previous  floor.  (Performed  oy  Elevator) 

R3c:  Illuminate  the  light  on  the  location  panel  for  the  current  floor.  (Per¬ 
formed  by  Elevator) 

R3u:  If  the  floor  is  listed  in  the  destination  list  for  the  elevator,  then  stop 
the  elevator  at  the  floor  and  extinguish  the  light  behind  the  floor 
number  on  the  elevator’s  control  panel.  After  stopping,  remove  the 
floor  from  the  destination  list,  wait  3  seconds,  then  proceed  to  the 
next  destination.  (Performed  by  Elevator) 

R3e:  If  the  floor  and  direction  are  listed  in  the  outstanding  request  list, 
then  stop  the  elevator  at  the  floor.  Extinguish  the  light  behind  the 
floor  button  on  the  proper  request  panel,  and  remove  the  summons 
request  from  the  outstanding  request  list.  After  stopping,  wait  3 
seconds,  then  proceed  to  the  next  destination.  (Performed  by  Ele¬ 
vator  Control  System) 

E4:  A  passenger  presses  a  destination  button  on  the  control  panel  of  a 
particular  elevator  (interrupt). 

Sender:  Elevator  Control  Panel 
Receiver:  Elevator 

Il4a:  Read  the  control  panel  input  register  to  determine  the  desired  floor 
number.  (Performed  by  Control  Panel) 

Rib:  Illuminate  the  ligbf  behind  the  button  on  the  control  panel  for  tin' 
elevator.  (Performed  by  C’ontrol  Panel) 

Rlc:  Add  the  floor  to  the  destination  list  for  the  elevator.  (Performed  by 
Elevator) 

E5:  An  elevator  becomes  overloaded. 

Inquiry  Sender:  Elevator 
Inquiry  Receiver:  Weight,  Sensor 

Roa:  Disable  the  elevator  so  that  it  does  not  move  until  the  overload 
condition  is  gone.  (Performed  by  Elevator) 

Rob:  Periodically  (approximately  every  o.(J  seconds)  check  to  set'  if  the 
overload  is  eliminated.  (Performed  by  Elevator) 

I. tv  I  line  to  check  elevator  weight  sensor  (periodic)- 


Rfi:  If  current  weight  is  less  than  max  load,  then  respond  to  commands. 
Otherwise,  delay  another  5  seconds  and  check  the  weight  sensor 
again.  (Performed  by  Elevator) 

1 .11  Documentation  of  Object  Classes 

The  remaining  pages  of  this  appendix  document  the  object  classes  as  entrit 
n  the  Object  Encyclopedia. 
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Elevator  Control  System 


Textual  Description: 

The  Elevator  Control  System  is  the  main  object  of  the  system.  If  contain- 
-oft ware  models  of  the  UP  and  DOWN  request  panels,  and  each  of  the  four  elevator-. 
Eliis  is  a  high  level  actor  object  which  keeps  track  of  and  schedules  each  of  the 

elevators. 

The  elevator  control  system  keeps  track  of  the  outstanding  summons  reqtit  --  - 
and  schedules  elevators  to  meet  these  requests.  The  elevator  control  system  should 
schedule  the  elevators  efficiently  and  reasonably.  For  example,  if  someone  summons 
an  elevator  by  pushing  he  down  button  on  the  fourth  floor,  the  next  elevator  ilia! 
reaches  the  fourth  floor  traveling  down  should  stop  at  the  fourth  floor  to  accept  the 
passengers.  When  the  elevator  control  system  receives  a  summons  request,  it  should 
lir>t  determine  if  there  is  a  parked  elevator  to  send  to  answer  the  summons.  If  nut. 
when  an  elevator  reaches  its  final  destination  and  the  request  is  still  outstanding, 
the  free  elevator  should  be  sent  to  the  floor  to  answer  the  summons. 

Structure  Diagram,  Interface  Diagram,  and  State  Transition  Diagram: 

See  figures  ATI.  A. 21.  and  A. 25. 

Messages  received  by  class: 

Arrived  at  Floor  A  signal  that  an  elevator  has  arrived  at  a 

floor. 

1  p  Summons  Request  A  signal  than  an  I  P  summons  request  has 

been  issued. 

I  town  Summons  Request  A  signal  than  a  DOWN  summons  request 

has  been  issued. 


\  r. 


Messages  sent  by  class: 

Summons  Request. Create 

Control  Panel. Extinguish  Light 

List. Is  Empty 
List. Add  Item 
List. Remove  Item 
List . Is  In  List 

Floor.  Assignment 

Floor. Is  less  than 

Elevator. Final  Destination  Of 

E 1  e vator. Direction  Of 
Elevator. Floor  Number  Of 

E  leva  tor..1 Set  Direction 
E  le  >  at  or.  St  op  at  this  floor 

Elevator.*  Jo  I o  f  loor 


Create  a  summons  request  from  the  floor 
number  and  direction  . 

Signal  the  UP  or  DOWN  request  panel  to 
extinguish  one  of  its  lights  due  to  an  ele¬ 
vator  arrival. 

Test  if  the  list  is  empty. 

Add  a  summons  request  to  the  list. 

Remove  a  summons  request,  from  the  list. 

Checks  to  see  if  a  given  summons  request 
is  in  the  list. 

Assign  one  value  of  a  floor  number  to  an¬ 
other. 

Test  if  one  floor  number  is  less  than  the 
other. 

Returns  the  final  destination  of  the  eleva¬ 
tor. 

Returns  the  direction  of  the  elevator. 

Returns  the  eurrent  floor  whore  the  eleva¬ 
tor  is. 

Set  the  direction  of  an  idle  elevator. 

Signal  to  t  h('  elevator  to  stop  at  t  he  current 
floor. 

Signal  to  the  elevator  to  go  tin'  the  <_i t v< ■ ; ; 
floor. 


\  .!(> 


Elevator  ID. Assignment  Assign  one  value  of  an  Elevator  ID  to  an¬ 
other. 

Elevator  ID. Is  equal  Test  if  two  elevator  IDs  are  equal. 

Description  of  any  state  limitations: 

If  an  outstanding  request  is  still  pending  after  20  seconds,  poll  the  elevators  t 
see  if  any  is  free  to  respond  to  the  summons. 

List  of  exported  exceptions: 

None.  The  Elevator  Control  System  must  handle  all  errors  internally. 

List  of  exported  constants: 

None. 

Re-use  considerations: 

This  class  is  application  specific. 
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Figure  A. 23.  Elevator  Control  System:  Structure  '  ^ram 
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Figure  A. 24.  {"levator  Control  System:  Interface  Diagram 
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Elevator 


Textual  Description:  An  elevator  object  controls  the  movement  of  a  single  el¬ 
evator.  This  class  of  objects,  each  of  which  has  a  unique  Elevator  ID,  contains 
controllers  for  each  logical  component  of  the  elevator:  motor,  control  panel,  location 
panel,  weight  sensor,  and  floor  sensor.  The  elevator  has  a  direction  associated  with 
it.  and  maintains  a  list  of  destinations  entered  on  its  control  panel.  This  controllct 
will  move  the  elevator  to  each  floor  in  its  destination  list,  and  respond  to  requests 
relayed  through  the  elevator  control  system.  The  controller  handles  the  setting  of 
lights  on  the  location  panel  based  on  input  from  the  floor  sensors.  An  elevator  with 
no  outstanding  destination  requests  should  park  at  the  last  floor  it  visited.  An  ('leva¬ 
tor  should  not  reverse  its  direction  of  travel  until  if  has  reached  its  final  destination 
in  its  current  direction. 

Structure  Diagram,  Interface  Diagram,  and  State  Transition  Diagram: 

See  figures  A. 26,  A. 27,  and  A. 28. 

Messages  received  by  class: 

Go  to  Floor  Stop  the  elevator  at  the  given  floor. 

Stop  At  This  Floor  Stop  the  elevator  at  the  current  tloor. 

Set  Direction  Sets  the  direction  of  the  elevator.  (The 

elevator  direction  must  first  be  "Parked".) 

floor  Number  Of  Returns  the  current  location  (floor  num¬ 
ber)  where  the  elevator  is. 


Direction  Of 


Returns  the  current  direction  of  the  eleva¬ 
tor. 


Final  Destination  Of  Returns  the  floor  number  of  the  elevators 

final  destination  in  its  destination  list. 

Button  Pushed  This  is  a  signal  that  a  given  button  has 

been  pushed  on  the  control  panel,  indicat¬ 
ing  a  new  destination. 

Arrival  At  Floor  This  is  a  signal  from  the  elevator  floor  sen¬ 

sor  that  the  elevator  is  about  to  arrive  at 
a  given  floor. 


Messages  sent  by  class: 

Elevator  Motor. Up 

Elevator  Motor. Down 

Elevator  Motor. Up 

Control  Panel. Extinguish  Light 

Elevator  ID. Assignment 
Location  Panel. Illuminate  Light 

Location  Panel. Extinguish  Light 


Signal  the  motor  to  move  the  elevator  up. 

Signal  the  motor  to  move  the  elevator 
Down. 

Signal  the  motor  to  stop  the  elevator. 

Signal  the  elevator  control  panel  to  extin¬ 
guish  the  light  for  the  current  floor. 

Assign  one  Elevator  ID  to  another. 

Signal  the  elevator  location  panel  to  illu¬ 
minate  the  light  of  the  floor  at  which  the 
elevator  is  about  to  arrive. 

Signal  the  elevator  location  panel  to  ext  in- 
guish  the  light  of  the  floor  the  elevator  is 
leaving. 
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Elevator  Control  System. Arrived  At  Floor  Signal  to  the  elevator  control  sys- 


Weight  Sensor. Check  Weight 


Weight  .Assignment 


Weight. Is  Less  Than 


Direction.  Assignment 


Direction. Is  Equal  To 


List. Is  Empty 


List. Is  In  List 


List. Remove  Item 


List. Add  Item 


tern  the  elevator  has  just  arrived  at 
a  floor. 

Check  the  current  weight  of  the  el¬ 
evator. 

Assign  the  weight  sensor  value  to 
the  current  weight  attribute. 

Determine  if  the  current  weight  is 
less  than  the  elevator's  load  capac¬ 
ity. 

Set  the  value  of  the  elevator's  direc¬ 
tion  attribute. 

Test  the  current  va me  of  the  di¬ 
rection  attribute  to  see  if  it  is 
“Parked" . 

Check  if  the  destination  list  is 
empty. 

Check  if  a  floor  number  is  in  the 
destination  list. 

Remove  a  floor  from  the  dest  inat  h  >n 
list  when  you  arrive  at  that  Hour. 

Add  a  floor  to  the  destination  list. 


Description  of  any  state  limitations: 

If  the  elevator  is  overweight,  the  elevator  controller  will  periodically  (every  live 
seconds)  check  the  weight  sensor  to  see  if  the  load  has  been  reduced.  T  he  elevator 
will  not  leave  t  he  “overweight"  state  until  the  sensor  reports  that  t  he  value  of  current 
weight  is  less  than  the  load  capacity. 
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List  of  exported  exceptions: 


Elevator  Busy  An  attempt  was  made  to  set  the  direc¬ 

tion  of  an  elevator  whose  direction  was  not 
klParked’\ 

Elevator  Overweight  An  attempt  was  made  to  direct  the  eleva¬ 
tor  to  another  floor  when  the  elevator  is 
overweight. 


List  of  exported  constants: 

.None. 

List  of  objects  in  class: 


•  Elevator  1 

•  Elevator  2 

•  Elevator  3 

•  Elevator  4 

Re-use  considerations: 

I  his  class  is  application  specific. 


All 


Figure  A. 26.  Elevator:  St rurt ure  Diagram 
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Elevator 

Motor 


Up 

Down 


Go  To  Floor 
Set  Direction 
Stop  At  This  Floor 
Floor  Number  Of 
Direction  Of 
Final  Destination  Of 
Button  Pushed 
Arrival  At  Floor 


Elevator 


Extinguish  Light 

f  Control  Y 
V  Panel  J 

Assignment  S' 


.Elevator  ID 


Illuminate  Light 
Extinguish  Light 

f  Locat  ion 
\  Panel 


Is  Empty 

Is  In  List 
Remove  Item 

~Add  Item/ 


.ed  At  Floor 

Elevator^^ 
Control  y 


L  Destination 
List 

Is  Equal  To 
\Assignment 

Direction  ] 


\  Assignment 
Jjls  Less  Than 

\.  Weight  ) 

j-  Load  Capacity 
Current  Weight 
iCheck  Weight 


Figure  A. 27.  Elevator:  Interface  Diagram 


Figure  A. 28.  Klevator:  State  Transition  Diagram 

I 

I 

I 
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Control  Panel 


Textual  Description: 

An  object  of  the  control  panel  class  drives  a  hardware  control  panel.  It  handles 
the  interrupts  raised  by  pressing  buttons  on  the  panel,  determines  which  button  is 
pressed,  and  automatically  lights  the  lamps  behind  the  buttons.  The  control  pane!  is 
contained  within  a  parent  object,  and  sends  a  message  to  this  object  when  a  button 
is  pushed.  The  control  panel  uses  input  and  output  registers  to  communicate  with 
the  hardware. 

Structure  Diagram,  Interface  Diagram,  and  State  Transition  Diagram: 

See  figures  A. 29,  A. 30,  and  A. 31. 

Messages  received  by  class: 

Extinguish  Eight,  Extinguish  a  light  behind  a  button  on  the 
control  panel. 

Button  Pushed  This  is  a  signal  (interrupt)  from  the  hard¬ 
ware  that  a  button  on  the  control  panel 
has  been  pushed  and  the  button  number  is 
in  the  input  register. 


Messages  sent  by  class: 

Interrupt  Number. Assignment  Assign  a  value  of  one  object  to  another 

when  initializing  the  control  panel. 

Address.  Assignment  Assign  a  value  of  one  address  objec  t  i  tor 

t he  input  and  output  registers)  to  another 
when  initializing  the  control  panel. 


Hutton  Hushed 


A  message  to  the  receiver  that  a  contr<>i 
p'  nel  button  lias  bee  n  pushed. 
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Input  Register. Read  Read  the  floor  number  from  the  input  reg¬ 
ister. 

Output  Register. VV rite  Write  the  floor  number  to  the  output  reg¬ 
ister. 

Floor. Assignment  Assign  the  value  of  one  object  to  another 

floor  object. 

Description  of  any  state  limitations: 

When  the  control  panel  writes  a  floor  number  to  the  output  register,  that  light 
is  toggled.  Therefore,  the  message  Extinguish  Light  could  actually  illuminate  the 
light.  The  control  panel  driver  assumes  that  the  light  specified  in  this  message  is 
actually  on.  This  is  a  safe  assumption  in  this  system  since  the  elevator  or  elevator 
control  system  will  maintain  a  list  (destination  list  and  outstanding  response  list )  of 
those  control  panel  buttons  that  are  pressed. 

List  of  exported  exceptions: 

None. 

List  of  exported  constants: 

None. 

List  of  objects  in  class: 


•  Elevator  1  Control  Panel 

•  Elevator  2  Control  Panel 

•  Elevator  A  Control  Panel 

•  Elevator  1  Control  Panel 

•  I  P  Request.  Panel 

•  DOW  N  Request  Panel 
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Re-use  considerations: 


This  class  has  re-use  potential.  If  re-used,  take  note  of  the  discussion  under 
the  State  Limitations  section. 


Figure  A. 29.  Control  Panel:  Structure  Diagram 


A-'.U 


extinguish  light 

button  pushed  (interrupt) 


Control 
^  Panel 


assignment 


assignment 


write 


Interrupt 

VNumboo 


assignment 


Address 


Button  Pushed 


Output 

Register 


Input 

Register 


Input  Register  Address 
Output  Register  Address 


Figure  A. 30.  Control  Panel:  Interface  Diagram 


Address 

Textual  Description: 

An  address  specifies  the  memory  location  of  an  input  or  output  register.  Th 
address  is  implemented  in  eight  bits. 

Structure  Diagram,  Interface  Diagram,  and  State  Transition  Diagram: 

<5  —  fin-,,—  \  to  *  oo  — \  *  f  < 

Messages  received  by  class: 

Assignment  Assign  the  value  of  one  address  object  to 
another. 

Messages  sent  by  class: 

None. 

Description  of  any  state  limitations: 

An  object  of  type  address  must  have  a  value  in  the  range  0..256.  An  add  res 
object,  must  be  initialize  before  it  can  be  read. 

List  of  exported  exceptions: 

Constraint  Error  The  value  ass!  >  '  to  the  object  is  not  in 
the  proper  rant 

List  of  exported  constants: 

Max  Address  —  256 
Re-use  considerations: 

[his  class  is  potentially  re-usable. 
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Figaro  A. 32.  Address:  Struct  are  Diagram 


'igure  A. 31.  Address:  Slate  Transition  diagram 


Direction 


Textual  Description: 

The  direction  class  specifies  the  direction  of  an  elevator.  The  values  of  a 
object  of  this  class  are  “UP”,  "DOWN”,  or  "Parked”. 

Structure  Diagram,  Interface  Diagram,  and  State  Transition  Diagram: 

See  figures  A. 35.  A. 36,  and  A. 37. 

Messages  received  by  class: 

Assignment  Assign  the  value  of  one  direction  object  to 
another. 

Is  Equal  To  Test  to  see  if  two  direction  objects  have  the 
s,  me  value. 

Messages  sent  by  class: 

None. 

Description  of  any  state  limitations: 

The  values  of  an  object  of  this  class  are  "UP".  “DOWN",  or  "Parked".  A 
object  of  this  class  may  not  be  read  until  it  has  been  assigned  a  value. 

List  of  exported  exceptions: 

Constraint  Error  The  value  assigned  to  an  object  of  this  class 
is  not  “UP”,  "DOWN",  or  "Parked". 
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List  of  exported  constants: 


The  following  values  are  visible:  "UP'’,  “DOWN",  or  “Parked" 
Re-use  considerations: 

This  class  is  application  specific. 


^Direction 


Value 


can  be 


can  be 


can  be 


Down 


Parked 


Figure  A. 35.  Direction:  Structure  Diagram 


assignment 
is  equal  to 


Direction 


Figure  A. 36.  Direction:  Interface  Diagram 


Elevator  ID 


Textual  Description: 

An  elevator  ID  is  simply  an  integer  identifier  used  to  identify  an  elevator  ol>je< 

Structure  Diagram,  Interface  Diagram,  and  State  Transition  Diagram: 

Sec  figures  A. 38,  A. 39,  and  A. 40. 

Messages  received  by  class: 

Assignment  Assign  the  value  of  one  Elevator  ID  object 
to  another. 


Is  equal  Test  if  two  Elevator  IDs  are  equal. 

Messages  sent  by  class: 

None. 

Description  of  any  state  limitations: 

The  value  of  an  object  of  this  class  is  limited  to  the  range  1..4.  An  object 
this  class  may  not  be  read  until  in  has  been  assigned  a  value. 

List  of  exported  exceptions: 

Constraint  Error  The  value  assigned  to  an  object  of  this  class 
is  not  in  the  range  1..4. 


List  of  exported  constants: 

None. 

Re-use  considerations: 

I  his  class  is  application  specific. 
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Elevator  Motor 


Text  us’  d  escription: 

This  class  of  objects  controls  the  motor  of  an  elevator.  It  responds  to  comma 
sent  as  messages  by  loading  the  proper  control  word  into  the  physical  output  | 
that  controls  the  elevator  motor.  The  commands  are:  Dp  —  16#0I#.  Down 
Stop  - 

Structure  Diagram,  Interface  Diagram,  and  State  Transition  Diagram 

See  figures  A. 41.  A.  12,  and  A.  IT 
Messages  received  by  class: 

!  ’p  Set  the  motor  to  raise  the  elevator. 

Down  Set  t  he  motor  to  lower  t  ho  elevator. 

Stop  Set  the  motor  to  stop  the  elevator. 


Messages  sent  by  class: 

Output  Register. Write 

Address.  Assign  merit 


Write  a  control  word  to  the  output  register. 

Assign  one  address  object's  value  to  all¬ 
ot  her. 


Description  of  any  state  limitations: 

Nolle. 

List  of  exported  exceptions: 

N’i  ine. 
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List  of  exported  constants: 

None. 

List  of  ''Njects  in  class: 

•  Elevator  l  Motor 

•  Elevator  2  Motor 

•  Elevator  3  Motor 

•  Elevator  1  Motor 

Re-use  considerations: 

This  class  is  application  specific. 


Eigur<  A. 11.  Elevator  Motor:  Structure  Diagram 
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Floor 


Textual  Description: 

This  class  of  objects  defines  the  floor  numbers  that  an  elevator  can  stop  at. 
The  floor  number  is  implemented  in  eight  bits  so  that  it  can  fit  in  the  input  and 
output  registers. 

Structure  Diagram,  Interface  Diagram,  and  State  Transition  Diagram: 

See  figures  A. 44,  A. 45,  and  A.u6. 

Messages  received  by  class: 

Assignment  Assign  the  value  of  one  floor  object  to  an¬ 
other. 

Is  Equal  Test  to  see  if  two  floor  objects  have  the 

same  value. 

Is  Less  Than  Test  to  see  if  one  floor  value  is  less  than 
the  other. 


Messages  sent  by  class: 

None. 

Description  of  any  state  limitations: 

The  value  of  an  object  of  this  class  must  be  in  the  range  1 . .10.  An  object  o, 
this  class  rrtav  not  be  read  until  it  has  been  assigned  a  value. 

List  of  exported  exceptions: 

Constraint  Error  The  value  assigned  to  an  object  of  this  class 
is  not  in  the  range  ] ..40. 


List  of  exported  constants: 

lop  Floor  —  40 
Re-use  considerations: 

I  his  "las:  is  application  specific. 
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Floor  Sensor 


Textual  Description: 

This  class  of  objects  manages  the  elevator  floor  sensors.  When  the  physica 
floor  sensor  triggers  an  interrupt  and  writes  the  floor  number  in  an  input  register 
this  floor  sensor  manager  reads  the  register  and  sends  a  message  to  some  receiver 
In  this  system,  the  receiver  is  always  an  elevator. 

Structure  Diagram,  Interface  Diagram,  and  State  Transition  Diagram: 

See  figures  ATT,  A. 48,  and  A. 49. 

Messages  received  by  class: 

Arrival  At  Floor  This  is  a  signal  (interrupt)  from  the  hard¬ 
ware  that  the  elevator  is  approaching  the 
floor  whose  number  is  in  the  input  register. 

Messages  sent  by  class: 

Address. Assignment  Assign  the  value  of  the  input  register  ad¬ 

dress  into  it’s  object  at  initialization. 

Input  Register. Read  Read  the  floor  number  from  the  floor  sen¬ 

sor  input  register. 

Arrival  At  Floor  A  message  to  the  receiver  that  an  elevator 

has  reached  a  floor. 

Floor.  Assignment  Assign  the  value  of  one  floor  ob  ject  to  an¬ 

other. 

Interrupt  Number. Assignment  Assign  the  value  of  the  floor  sensor  inter¬ 
rupt  into  its  attribute  at  initialization. 


Description  of  any  state  limitations: 

None. 

List  of  exported  exceptions: 

None. 

List  of  exported  constants: 

None. 

bf  List  of  objects  in  class: 

•  Elevator  1  Floor  Sensor 

•  Elevator  2  Floor  Sensor 

•  Elevator  3  Floor  Sensor 

•  Elevator  4  Floor  Sensor 

Re-use  considerations: 

This  class  has  limited  re-use  potential. 


Figure  A. 47.  Floor  Sensor:  Structure  Diagram 
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Figure  A. 48.  Floor  Sensor:  Interface  Diagram 


Input  Register 


Textual  Description: 

An  input  lcgister  is  a  hardware  entity,  but  in  many  ways  acts  like  a  software 
In  this  system,  the  input  register  will  contain  a  bit  pattern  (eight  bits)  which 
r;ul  -  interpreted  as  values  of  class  floor  or  weight  as  appropriate  when  read  by 
,M.he:  objects. 

Structure  Diagram,  Interface  Diagram,  and  State  Transition  Diagram: 

see  figures  A. 50,  and  A. 51.  A  state  transition  diagram  is  not  appropriate  fur 

this  .ass. 

Messages  received  by  class: 

Read  Read  the  value  in  the  input  register. 

Messages  sent  by  class: 

None. 

Description  of  any  state  limitations: 

None. 

List  of  exported  exceptions: 

N/A 

List  of  exported  constants: 

N/A 

List  of  objects  in  class: 


•  Elevator  1  Weight  Sensor  Register 

•  Elevator  2  Weight  Sensor  Register 

•  Elevator  3  Weight  Sensor  Register 

•  Elevator  4  Weight  Sensor  Register 

•  Elevator  1  Control  Panel  Input  Register 

•  Elevator  2  Control  Panel  Input  Register 

•  Elevator  3  Control  Panel  Input  Register 

•  Elevator  4  Control  Panel  Input  Register 

•  Elevator  1  Floor  Sensor  Input  Register 

•  Elevator  2  Floor  Sensor  Input  Register 

•  Elevator  3  Floor  Sensor  Input  Register 
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•  Elevator  4  Floor  Sensor  Input  Register 

•  UP  Summons  Panel  Input  Register 

•  DOWN  Summons  Panel  Input  Register 

Re-use  considerations: 

This  is  a  description  of  a  hardware  entity  and  thus  has  no  software  re-use 
potential. 


Figure  A. 50.  Input  Register:  Structure  Diagram 


Figure  A. 51.  Input  Register:  Interface  Diagram 
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Interrupt  Number 

Textual  Description: 

This  class  defines  the  interrupt  numbers.  Valid  interrupt  numbers  are  those 
which  can  be  represented  in  eight  bits. 

Structure  Diagram,  Interface  Diagram,  and  State  Transition  Diagram: 

See  figures  A. 52,  A. 53,  and  A. 54. 

Messages  received  by  class: 

Assignment  Assign  a  value  to  an  Interrupt  Number  ob¬ 
ject. 

Messages  sent  by  class: 

None. 

Description  of  any  state  limitations: 

The  value  of  an  object  of  this  class  must  be  in  the  range  0..255.  An  object  o! 
this  class  may  not  be  read  until  it  has  been  assigned  a  value. 

List  of  exported  exceptions: 

Constraint  Error  The  value  assigned  to  an  object  of  this  class 
is  not  in  the  range  0..256. 


List  of  exported  constants: 

None. 

List  of  objects  in  class: 

•  Elevator  1  Control  Panel  Interrupt 

•  Elevator  2  Control  Panel  Interrupt 

•  Elevator  3  Control  Panel  Interrupt 

•  Elevator  4  Control  Panel  Interrupt 

•  Elevator  1  Floor  Sensor  Interrupt 

•  Elevator  2  Floor  Sensor  Interrupt 

•  Elevator  3  Floor  Sensor  Interrupt 
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•  Elevator  4  Floor  Sensor  Interrupt 

•  UP  Summons  Request  Panel  Interrupt 

•  DOWN  Summons  Request  Panel  Interrupt 


Re-use  considerations: 


This  class  has  limited  re-use  potential. 


Figure  A. 52.  Interrupt  Number:  Structure  Diagram 


A  -72 


List 

Textual  Description: 

I  he  list  class  models  a  bounded  list  of  items.  Items  ran  be  added,  or  removed 
from  the  list,  as  well  as  tested  for  inclusion  in  the  list. 

Structure  Diagram,  Interface  Diagram,  and  State  Transition  Diagram: 

See  figures  A. 55,  A. 56,  and  A. 57. 

Messages  received  by  class: 

Is  Empty  Test  to  see  if  the  list  is  empty  of  items. 

Is  In  List  Test  to  see  if  a  given  item  is  in  the  list. 

Add  Item  Add  an  item  to  the  list. 

Remove  Item  Remove  an  item  from  the  list. 

Messages  sent  by  class: 

Is  Equal  Test  if  two  items  are  equal  {required  from 
class  of  item). 

Assignment  Assign  the  value  of  one  item  to  another 
( required  from  class  of  item). 

Description  of  any  state  limitations: 

No  item  ran  be  removed  from  an  empty  list,  nor  added  to  a  full  list. 
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List  of  exported  exceptions: 

Overflow  Attempt  was  made  to  add  to  a  full  list. 

Underflow  Attempt  was  made  to  remove  from  an 
empty  list. 

List  of  exported  constants: 

Size  —  The  size  of  the  list. 

Re-use  considerations: 


1  his  class  is  potentially  re-usable. 


Figure  A. 57.  List:  Slate  Transition  Diagram 


I 

I 
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Location  Panel 


Textual  Description: 

This  class  controls  the  operation  of  the  location  panel  hardware  of  an  elevator. 
The  class  responds  to  messages  to  illuminate  and  extinguish  tights  in  the  panel.  It 
does  so  by  outputing  the  floor  number  of  the  light  to  the  location  panel  output 
register.  The  class  maintains  a  list  of  previously  illuminated  lamps  (of  which  there 
should  be  only  one).  The  location  panel  will  only  extinguish  lights  which  were 
previously  illuminated. 

Structure  Diagram,  Interface  Diagram,  and  State  Transition  Diagram: 

See  figures  A. 58,  A. 59,  and  A. 60.  The  state  transition  diagram  describes  the 
activity  of  a  single  light  on  the  panel. 

Messages  received  by  class: 

Illuminate  Light  Illuminate  a  new  light  on  the  location 
panel. 

Extinguish  Light  Extinguish  a  light  on  the  location  panel. 

Messages  sent  by  class: 

Floor. Assignment  Assign  a  floor  number  value  to  the  floor 

number  attribute. 

Address. Assignment  Assign  the  output  register  address  to  the 

attribute  at  initialization. 

Output  Register. Write  Write  the  floor  number  to  the  location 

panel  output  register  to  toggle  the  light. 
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List. Remove  Item  Remove  a  floor  number  from  the  list  of  il¬ 
luminated  lights. 

List. Add  Item  Add  a  floor  number  to  the  list  of  illumi¬ 

nated  lights. 

List. Is  In  List  Test  to  see  if  a  floor  number  is  in  the  list 
of  illuminated  lights. 

Description  of  any  state  limitations: 

The  location  panel  controller  will  check  its  status  list  before  sending  writing 
to  the  output  port  to  toggle  the  light.  Therefore,  it  will  preclude  the  possibility  of 
toggling  the  light  off  when  it  should  be  illuminating  it,  and  vice  versa. 

List  of  exported  exceptions: 

None. 

List  of  exported  constants: 

None. 

List  of  objects  in  class: 

•  Elevator  1  Location  Panel 

•  Elevator  2  Location  Panel 

•  Elevator  3  Location  Panel 

•  Elevator  4  Location  Panel 

Re-use  considerations: 

This  class  has  limited  re-use  potential. 


Figure  A. 58.  Location  Panel:  Structure  Diagram 


Figure  A. 59.  Location  Panel:  Interface  Diagram 
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Output  Register 


Textual  Description: 

An  output  register  is  a  hardware  entity,  but  in  many  ways  can  be  though; 
as  a  software  entity.  In  this  system,  the  output  register  will  be  written  a  bit  patt, 
(eight  bits)  which  is  interpreted  by  other  hardware  devices  to  be  a  floor  number 

Structure  Diagram,  Interface  Diagram,  and  State  Transition  Diagram 

See  figures  A. 61  and  refoorid.  A  state  transition  diagram  is  not  appropri 

for  this  class. 

Messages  r.ceived  by  class: 

Write  Write  the  value  into  the  output  register. 

Messages  sent  by  class: 

None. 

Description  of  any  state  limitations: 

None. 

List  of  exported  exceptions: 

X/A 

List  of  exported  constants: 

N/A 

List  of  objects  in  class: 

•  [-'.levator  1  Location  Panel  Output  Register 

•  Klevator  2  Location  Panel  Output  Register 

•  klevator  3  Location  Panel  Output  Register 

•  klevator  1  Location  Panel  Output  Register 

•  klevator  1  Control  Panel  Output  Register 

•  klevator  2  Control  Panel  Output  Register 

•  klevator  3  Control  Panel  Output  Register 
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•  Elevator  4  Control  Panel  Output  Register 

•  Elevator  1  Motor  Control  Register 

•  Elevator  2  Motor  Control  Register 

•  Elevator  3  Motor  Control  Register 

•  Elevator  4  Motor  Control  Register 

•  Up  Summons  Panel  Output  Register 

•  DOWN  Summons  Panel  Output  Register 

Re-use  considerations: 

This  is  a  description  of  a  hardware  entity  and  thus  has  no  software  re-use 
potential. 


Figure  A. 61.  Output  Register:  Structure  Diagram 


f  igure  A. 62.  Output  Register:  Interface  Diagram 
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Summons  Request 

Textual  Description: 

The  summons  request  class  describes  a  structure  which  contains  the  important 
information  about  a  summons  request:  its  floor  and  direction.  An  object  of  this  type 
is  useful  for  placing  in  a  list  of  requests  for  further  processing. 

Structure  Diagram,  Interface  Diagram,  and  State  Transition  Diagram: 

See  figures  A. 63,  A. 64,  and  A. 65. 

Messages  received  by  class: 

Create  Create  a  summons  request  value  from  a 

floor  number  and  direction. 

Is  Equal  Test  the  values  of  two  summons  request 
objects  to  see  if  they  are  equal. 

Assignment  Assign  a  summons  request  value  to  anot  her 
object. 

Messages  sent  by  class: 

Floor.  Assignment 

Floor. Is  Equal 

Direction.  Assignment 

Direction. Is  Equal 


Assign  VliW  floor  number  to  the  summons 
request  component  when  creating  a  sum¬ 
mons  request. 

Test  to  see  if  the  floor  number  components 
of  two  summons  requests  are  equal. 

Assign  the  direction  to  the  summons  re¬ 
quest  component  when  creating  a  sum¬ 
mons  request. 

Test  to  see  if  the  direction  components  of 
two  summons  requests  are  equal. 


Description  of  any  state  limitations: 

Ihe  floor  number  and  direction  components  must  each  have  legal  values  ior 
i  hos  •  respective  classes.  An  object  of  this  class  may  not  lie  read  until  it  has  been 
created  via  the  create  message. 
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List  of  exported  exceptions: 

Constraint  Error  The  value  of  the  floor  number  or  direction 
assigned  to  an  object  of  this  class  is  not  in 
the  proper  range  for  its  class. 


List  of  exported  constants: 

None. 

Re-use  considerations: 

This  class  is  application  specific. 


Figure  A. 63.  Summons  Request:  Structure  Diagram 
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Figure  A. 64.  Summons  Request:  Interface  Diagram 
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Weight 

textual  Description: 

This  class  of  objects  defines  the  weight  of  an  entity,  in  this  case  elevators.  The 
units  for  this  class  are  in  hundreds  of  pounds.  The  type  must  be  implemented  in 
eight  bits,  since  its  value  is  taken  from  an  input  register. 

Structure  Diagram,  Interface  Diagram,  and  State  Transition  Diagram: 

See  figures  A. 66,  and  A. 67.  A  state  transition  diagram  is  not  required  for  this 

class. 

Messages  received  by  class: 

Assignment  Assign  a  weight  value  to  an  object. 

Is  Less  Than  Test  to  see  if  one  value  of  weight  is  less  t  han 
another. 


Messages  sent  by  class: 

None. 

Description  of  any  state  limitations: 

The  value  of  an  object  of  this  class  must  be  in  the  range  0..255.  An  object  of 
this  class  may  not  be  read  until  it  has  been  assigned  a  value. 

List  of  exported  exceptions: 

Constraint  Error  The  value  assigned  to  an  object  of  t  his  class 
is  not  in  the  range  0..255. 


List  of  exported  constants: 

Max  Weight  —  255 
Re-use  considerations: 

This  class  is  application  specific. 
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Figure  A. 66.  Weight:  Structure  Diagram 


Figure  A. 67.  Weight:  Interface  Diagram 
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Weight  Sensor 


Textual  Description: 

This  class  of  objects  manages  the  weight  sensor  for  an  elevator.  The  physic, 
weight  sensor  periodically  places  a  weight  value  in  an  input  register.  When  a  weig! 
check  is  requested,  a  weight  sensor  object  will  read  the  weight  sensor  input  regisu 
and  return  the  weight  value. 

Structure  Diagram,  Interface  Diagram,  and  State  Transition  Diagram: 

See  figures  A. 68,  A. 69,  and  A. TO. 

Messages  received  by  class: 

Check  Weight  Read  the  weight  sensor  input  register  and 
return  the  weight  value. 

Messages  sent  by  class: 

Weight. Assignment  Assign  the  weight  value  from  the  input  reg¬ 
ister  to  the  current  weight  attribute. 

Input  Register. Read  Read  the  weight,  value  from  the  weight  sen¬ 
sor  input  register. 

Address. Assignment.  Assign  the  address  of  the  input  register  to 

its  attribute  at  initialization. 

Description  of  any  state  limitations: 

None. 

List  of  exported  exceptions: 

None. 

List  of  exported  constants: 

None. 
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List  of  objects  in  class: 


•  Elevator  1  Weight  Sensor 

•  Elevator  2  Weight  Sensor 

•  Elevator  3  Weight  Sensor 

•  Elevator  4  Weight  Sensor 

Re-use  considerations: 

This  class  has  limited  re-use  potential. 


Figure  A.f>8.  Weight  Sensor:  Structure  Diagram 
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Figure  A. 69.  Weight  Sensor:  Interface  Diagram 


igureA.iO.  Weight  Sensor:  State  Transition  Diagra 
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